세상 어디에도 없는 블로그

스마트폰 화면을 바라보는 것만으로 잠금이 풀리고, 손가락을 센서에 올리면 결제가 승인되는 경험은 이제 낯설지 않습니다.

이 과정에서 카메라나 지문센서가 생체정보를 읽는 것만으로 인증이 끝나는 것은 아닙니다.

센서에서 들어온 데이터를 분석하고, 개인을 구분할 수 있는 특징을 추출하고, 등록된 정보와 비교한 뒤 최종적으로 접근을 허용할지 결정하는 바이오인식 소프트웨어가 그 중심에서 작동합니다.

바이오인식은 비밀번호를 대신하는 편리한 기술이지만 생체정보는 한 번 유출되면 비밀번호처럼 쉽게 바꿀 수 없다는 특성이 있습니다.

따라서 정확한 인식률뿐 아니라 템플릿 보호와 위조 공격 방어, 개인정보 최소화, 안전한 저장까지 함께 고려해야 제대로 된 바이오인식 시스템이라고 할 수 있습니다.

바이오인식 소프트웨어는 실제로 무엇을 처리할까?

바이오인식은 사람이 가지고 있는 신체적 또는 행동적 특징을 이용해 신원을 확인하는 기술입니다.

신체적 특징으로는 지문과 얼굴, 홍채 등이 대표적이며 행동적 특징으로는 음성과 서명 동작, 키 입력 습관, 걸음걸이 등이 활용될 수 있습니다.

바이오인식 소프트웨어는 이러한 정보를 센서에서 전달받은 뒤 곧바로 사람의 이름을 찾아내는 것이 아닙니다.

먼저 입력 데이터의 품질을 평가하고 필요한 영역을 찾아낸 뒤 개인을 구분할 수 있는 특징을 계산합니다.

지문에서는 융선의 끝점과 분기점 같은 특징을 사용할 수 있고 얼굴인식에서는 과거처럼 눈·코·입 사이의 거리만 계산하는 방식보다 인공지능 모델을 통해 얼굴 전체의 특징을 고차원 수치 표현으로 변환하는 방식이 널리 사용됩니다.

이러한 수치 표현을 등록된 정보와 비교하여 두 데이터가 같은 사람에게서 나온 것인지 판단합니다.

즉 바이오인식 소프트웨어는 단순한 이미지 비교 프로그램이라기보다 신호처리·인공지능·보안·데이터관리·판정 기능이 결합된 인증시스템에 가깝습니다.

등록부터 인증까지 어떤 과정을 거칠까?

바이오인식 시스템을 사용하려면 일반적으로 먼저 등록 과정이 필요합니다.

사용자의 지문이나 얼굴, 홍채 등을 한 번 또는 여러 번 획득하고 품질이 충분한지 확인한 뒤 비교에 사용할 특징정보를 생성합니다.

이때 만들어지는 것이 바이오인식 템플릿입니다.

템플릿은 일반적으로 원본 얼굴사진이나 지문영상 그 자체와는 다른 형태의 특징정보입니다.

하지만 템플릿이라고 해서 자동으로 익명정보가 되거나 절대로 원래 생체특성을 추정할 수 없는 것은 아닙니다.

알고리즘과 저장방식에 따라 재구성이나 교차매칭의 위험이 있을 수 있기 때문에 템플릿 역시 매우 민감한 정보로 보호해야 합니다.

인증이 시작되면 센서에서 새로운 생체정보를 획득하고 같은 방식으로 특징을 추출합니다.

이 특징과 등록된 템플릿의 유사도를 계산하면 하나의 매칭 점수가 만들어집니다.

점수가 시스템에서 정한 기준을 충족하면 일치로 판단하고 그렇지 않으면 거부합니다.

여기서 기준값을 너무 낮추면 다른 사람을 본인으로 받아들일 가능성이 높아지고, 너무 높이면 정상 사용자까지 거부하는 일이 많아집니다.

따라서 실제 시스템에서는 사용 목적과 위험도에 맞춰 적절한 임계값을 설정하는 것이 매우 중요합니다.

1:1 본인 확인과 1:N 식별은 어떻게 다를까?

바이오인식에서는 본인 확인과 식별을 구분합니다.

본인 확인은 사용자가 먼저 자신이 누구인지 주장하고 이를 생체정보로 확인하는 방식입니다.

예를 들어 직원번호를 입력한 뒤 지문을 대는 경우 시스템은 해당 직원번호와 연결된 템플릿 하나를 현재 지문과 비교합니다.

이를 일반적으로 1:1 비교라고 합니다.

스마트폰의 얼굴 잠금해제나 지문인식 역시 기본적으로 기기에 등록된 사용자의 생체정보와 비교한다는 점에서 본인 확인 방식으로 볼 수 있습니다.

반면 식별은 현재 입력된 생체정보가 데이터베이스에 등록된 사람들 가운데 누구인지를 찾는 과정입니다.

하나의 입력을 여러 후보와 비교하기 때문에 1:N 비교라고 부릅니다.

대규모 얼굴 검색이나 지문 데이터베이스 검색 등이 대표적인 예입니다.

1:N 시스템은 데이터베이스가 커질수록 비교해야 하는 후보가 많아지므로 검색속도와 잘못된 후보가 나올 가능성을 함께 관리해야 합니다.

따라서 스마트폰 잠금해제와 대규모 신원검색은 모두 바이오인식을 사용하지만 기술적으로 같은 문제라고 볼 수는 없습니다.

인식률이 99%라는 말만으로 성능을 판단할 수 있을까?

바이오인식의 성능은 단순히 하나의 정확도 숫자로 설명하기 어렵습니다.

가장 중요한 오류 가운데 하나는 서로 다른 사람인데 같은 사람으로 판단하는 것입니다.

반대로 실제 등록된 사용자인데 시스템이 다른 사람으로 판단하여 거부할 수도 있습니다.

이 두 오류는 일반적으로 잘못된 일치와 잘못된 불일치로 구분해 평가합니다.

실무와 제품 문서에서는 FAR과 FRR이라는 표현도 널리 사용되며, 국제적인 성능평가에서는 보다 구체적으로 FMR과 FNMR 같은 지표를 사용하기도 합니다.

중요한 것은 두 오류가 서로 독립적이지 않다는 점입니다.

판정 기준을 엄격하게 만들면 다른 사람을 받아들이는 가능성은 줄지만 정상 사용자를 거부하는 일이 늘어날 수 있습니다.

반대로 기준을 느슨하게 하면 사용 편의성은 높아지지만 보안 위험이 증가할 수 있습니다.

EER은 두 종류의 오류율이 같아지는 지점을 나타내며 알고리즘의 특성을 비교할 때 참고할 수 있습니다.

하지만 EER이 낮다는 이유만으로 실제 모든 환경에서 가장 우수한 시스템이라고 단정할 수는 없습니다.

공항 출입통제처럼 잘못된 허용을 매우 엄격하게 관리해야 하는 환경과 일반 소비자 기기의 잠금해제는 요구하는 오류 수준이 서로 다르기 때문입니다.

조명과 카메라 각도, 센서 상태, 사용자 연령, 피부 상태, 얼굴 가림 등 실제 환경 역시 성능에 큰 영향을 줍니다.

사진이나 가짜 지문으로 속이는 공격은 어떻게 막을까?

바이오인식 시스템의 중요한 보안문제 가운데 하나는 실제 사람 대신 위조된 생체정보를 센서에 제시하는 공격입니다.

얼굴인식 카메라에 사진이나 영상을 보여주거나 지문센서에 인공적으로 만든 지문을 접촉시키는 것이 대표적인 예입니다.

이런 공격을 일반적으로 제시 공격이라고 하며 이를 탐지하는 기술을 제시 공격 탐지라고 합니다.

흔히 사용하는 라이브니스 감지는 이러한 방어기술 가운데 하나입니다.

얼굴에서는 깊이정보와 적외선, 움직임, 피부의 반사특성 등을 분석할 수 있고 지문에서는 피부의 전기적·광학적 특성이나 변형 패턴 등을 이용할 수 있습니다.

하지만 라이브니스 기능이 있다고 모든 위조공격을 완벽하게 막을 수 있는 것은 아닙니다.

공격기술도 계속 발전하기 때문에 바이오인식 알고리즘과 위조방지 기술을 지속적으로 시험하고 개선해야 합니다.

또한 단말기의 보안영역과 센서 사이에서 데이터가 탈취되거나 템플릿 데이터베이스가 공격받을 가능성도 있으므로 센서만 안전하게 만드는 것으로는 충분하지 않습니다.

생체정보는 어디에 저장하는 것이 안전할까?

바이오인식에서는 템플릿을 어디에 저장하고 어디에서 비교할 것인지가 매우 중요합니다.

스마트폰과 같은 개인기기에서는 생체 템플릿을 단말기 내부의 별도 보안영역에 저장하고 외부 앱이나 서버가 원본 생체정보에 직접 접근하지 못하도록 설계하는 방식이 많이 사용됩니다.

반면 출입통제나 공공 신원확인처럼 여러 장소에서 동일한 사용자를 확인해야 하는 시스템에서는 중앙 서버나 분산된 데이터베이스를 사용할 수도 있습니다.

이 경우 템플릿 암호화와 접근통제, 키관리, 전송구간 보호, 감사로그가 중요해집니다.

템플릿 보호에는 단순한 데이터베이스 암호화 외에도 템플릿을 변환해 원래 형태의 사용을 어렵게 만드는 기술이나 취소 가능한 바이오인식 템플릿 같은 개념도 연구·활용됩니다.

이러한 기술이 중요한 이유는 비밀번호와 달리 생체특성 자체를 새로 발급받기가 어렵기 때문입니다.

지문 템플릿이 유출되었다고 새로운 손가락을 만들 수는 없습니다.

따라서 바이오인식에서는 인식 정확도 못지않게 템플릿 보호와 유출 이후 피해 확산을 막는 설계가 중요합니다.

FIDO에서는 지문이나 얼굴을 서버로 보내는 걸까?

바이오인식과 FIDO 인증은 자주 함께 언급되지만 생체정보를 서버에 직접 전송하는 시스템이라고 이해하면 정확하지 않습니다.

FIDO 계열 인증에서는 일반적으로 단말기 안에서 지문이나 얼굴을 이용해 사용자를 확인하고, 그 결과를 바탕으로 기기 안에 안전하게 보관된 개인키를 사용할 수 있도록 합니다.

서버에는 생체사진이나 지문 템플릿 대신 암호학적으로 생성된 인증 결과가 전달됩니다.

서버는 미리 등록된 공개키를 이용해 이 결과를 검증합니다.

이러한 구조를 사용하면 서비스 제공자가 사용자의 지문이나 얼굴 데이터를 직접 보관하지 않고도 강한 인증을 구현할 수 있습니다.

따라서 바이오인식은 FIDO에서 신원을 서버에 직접 증명하는 생체데이터 그 자체라기보다 사용자가 자신의 인증기기를 사용할 수 있도록 잠금을 해제하는 로컬 사용자 확인 수단으로 활용되는 경우가 많습니다.

이것은 바이오인식 데이터의 중앙집중적인 수집을 줄일 수 있다는 점에서도 중요한 의미가 있습니다.

어떤 분야에서 사용되고 있을까?

가장 친숙한 활용처는 스마트폰입니다.

지문이나 얼굴을 이용해 기기의 잠금을 해제하고 앱 로그인이나 결제 승인에 사용할 수 있습니다.

기업에서는 건물과 서버실 출입통제, 직원 인증, 중요 시스템 접근관리 등에 사용할 수 있습니다.

공항과 출입국 분야에서는 전자여권의 얼굴정보와 현장에서 촬영한 얼굴을 비교하여 여행자의 신원을 확인하는 데 활용할 수 있습니다.

다만 전자여권의 위변조 방지는 바이오정보 하나로 이루어지는 것이 아닙니다.

전자칩과 전자서명, 인증서 체계 등을 이용해 여권 데이터의 진위와 무결성을 검증하고 바이오인식은 여권 소지자가 실제 명의인과 일치하는지를 확인하는 데 도움을 줍니다.

금융서비스에서도 모바일뱅킹과 결제 승인에 바이오인식을 사용할 수 있습니다.

의료기관에서는 환자 식별이나 의료정보 접근통제 등에 적용할 수 있으며 자동차에서는 운전자 확인과 개인화된 좌석·환경설정 등에 활용될 수 있습니다.

범죄수사에서도 지문이나 얼굴 등을 이용한 후보자 검색이 활용될 수 있지만 이러한 용도는 일반적인 개인기기 인증보다 오인식이 미치는 영향이 훨씬 크기 때문에 정확성과 법적 절차, 사람의 최종 검토가 특히 중요합니다.

투표처럼 민감한 공공영역에서는 국가별 법과 제도가 크게 다르기 때문에 바이오인식이 일반적으로 사용된다고 단정하기보다는 일부 국가와 특정 제도에서 활용될 수 있다고 보는 것이 적절합니다.

바이오인식 정보가 개인정보 보호에서 특별히 중요한 이유

생체정보는 일반적인 계정정보와 다른 특징을 가지고 있습니다.

비밀번호가 유출되면 새 비밀번호로 변경할 수 있지만 얼굴과 홍채, 지문 같은 신체적 특징은 쉽게 변경할 수 없습니다.

따라서 개인을 고유하게 식별하기 위해 처리되는 바이오인식 정보는 매우 높은 수준의 보호가 필요합니다.

시스템을 설계할 때는 필요한 정보만 수집하고 사용 목적과 보관기간을 명확하게 관리하며 불필요한 원본 이미지를 오래 저장하지 않는 방향이 중요합니다.

누가 생체정보에 접근했는지를 기록하고 관리자의 접근권한도 최소화해야 합니다.

서비스를 종료하거나 보관목적이 사라진 뒤에는 관련 법과 정책에 따라 안전하게 삭제하는 절차가 필요합니다.

알고리즘의 공정성도 중요한 문제입니다.

얼굴인식 모델의 학습데이터가 특정 인구집단에 편중되어 있으면 집단별 인식성능 차이가 발생할 수 있습니다.

따라서 전체 평균 정확도만 확인하기보다 실제 사용대상에서 오류율에 의미 있는 차이가 있는지도 평가할 필요가 있습니다.

특히 공공서비스나 법집행처럼 잘못된 식별이 개인에게 큰 불이익을 줄 수 있는 분야에서는 자동 판정만으로 중요한 결정을 내리지 않도록 별도의 검토절차를 마련하는 것이 중요합니다.

바이오인식 표준은 왜 필요할까?

바이오인식 시스템은 센서와 알고리즘, 데이터베이스, 운영시스템이 서로 다른 제조사에서 만들어질 수 있습니다.

서로 다른 시스템 간에 데이터를 교환하고 성능을 객관적으로 평가하려면 공통된 데이터 형식과 시험방법이 필요합니다.

이를 위해 국제적으로 바이오인식 데이터 형식과 성능평가, 제시 공격 탐지 등에 관한 여러 표준이 만들어져 있습니다.

과거부터 널리 알려진 ISO/IEC 19794 계열은 지문과 얼굴, 홍채 등 바이오인식 데이터 교환 형식을 정의하는 데 중요한 역할을 해왔습니다.

최근에는 보다 확장성이 높은 ISO/IEC 39794 계열로 세대교체가 진행되면서 새로운 바이오인식 데이터 교환 형식이 발전하고 있습니다.

제시 공격 탐지와 관련해서는 ISO/IEC 30107 계열과 같은 국제표준도 활용됩니다.

표준을 적용하면 모든 제품의 인식성능이 동일해지는 것은 아니지만 데이터 호환성과 시험결과 비교, 시스템 통합을 쉽게 만드는 데 도움이 됩니다.

FAQ

바이오인식과 생체인증은 같은 말인가요?

비슷하게 사용되지만 바이오인식은 개인을 확인하거나 식별하는 전체 기술을 포괄하는 표현이고 생체인증은 그 가운데 사용자가 주장하는 신원을 확인하는 용도로 사용하는 경우가 많습니다.

얼굴 사진 자체를 서버에 저장하나요?

시스템마다 다릅니다. 원본 이미지를 보관하는 시스템도 있고 특징 템플릿만 저장하는 시스템도 있습니다. 개인정보 보호를 위해 목적상 필요하지 않은 원본 데이터를 최소화하는 것이 중요합니다.

바이오인식 템플릿은 유출되어도 괜찮은가요?

아닙니다. 원본 영상과 다른 형태라고 해도 개인을 식별하는 데 사용되는 중요한 정보이므로 유출되면 개인정보 침해와 교차매칭 등의 문제가 발생할 수 있습니다.

스마트폰 얼굴인식은 인터넷 서버에서 얼굴을 비교하나요?

기기와 서비스에 따라 다르지만 현대 스마트폰의 기기 잠금해제와 같은 기능은 생체정보를 단말 내부의 보안영역에서 처리하는 구조가 많이 사용됩니다.

1:1과 1:N 비교는 어떤 차이가 있나요?

1:1은 사용자가 주장한 신원과 등록된 템플릿 하나를 비교하는 본인 확인이고, 1:N은 데이터베이스의 여러 사람 가운데 입력된 생체정보와 일치하는 사람을 찾는 식별입니다.

라이브니스 감지는 무엇인가요?

사진이나 영상, 가짜 지문처럼 실제 사용자가 아닌 위조 생체정보를 센서에 제시하는 공격을 탐지하기 위한 기술입니다. 보다 넓게는 제시 공격 탐지의 한 형태로 볼 수 있습니다.

바이오인식이 비밀번호보다 무조건 안전한가요?

그렇지 않습니다. 생체정보는 기억할 필요가 없고 편리하지만 유출되었을 때 쉽게 변경하기 어렵다는 단점이 있습니다. 따라서 기기 보안과 템플릿 보호, 다중요소 인증을 함께 고려해야 합니다.

바이오인식 정확도가 100%가 될 수 있나요?

실제 환경에서는 센서 품질과 조명, 자세, 생체특성 변화, 알고리즘, 판정기준 등에 영향을 받기 때문에 오류 가능성을 완전히 없애기는 어렵습니다. 중요한 것은 사용 목적에 맞는 오류 수준을 정하고 지속적으로 성능을 평가하는 것입니다.

자동차 전자시스템은 오랫동안 기능 하나가 추가될 때마다 ECU를 하나씩 늘리는 방식으로 발전해왔습니다. 하지만 ADAS와 전동화, 커넥티드카와 인포테인먼트 기능이 급격히 늘면서 이러한 방식은 한계에 가까워지고 있습니다.

수많은 ECU와 통신망을 관리하려면 배선과 소프트웨어가 복잡해지고 새로운 기능을 개발하거나 OTA로 업데이트하는 것도 어려워집니다.

그래서 최근 자동차는 기능별 ECU를 더 강력한 도메인 컨트롤러로 통합하고, 다시 중앙 컴퓨터와 존 컨트롤러를 중심으로 재구성하는 방향으로 발전하고 있습니다. 이 과정에서 데이터와 서비스를 물리적인 ECU 위치와 분리하는 통신 추상화가 SDV Software-Defined Vehicle의 핵심 요소로 자리 잡고 있습니다.

분산 ECU 아키텍처

전통적인 자동차에서는 새로운 기능이 추가될 때 해당 기능을 담당하는 ECU를 별도로 장착하는 방식이 많이 사용되었습니다.

엔진 ECU와 변속기 ECU, 에어백 ECU, 차체 ECU 등이 각각 독립적으로 존재하는 구조입니다.

분산 구조의 장점

각 ECU가 자신의 기능에 집중하므로 시스템을 비교적 명확하게 분리할 수 있습니다.

특정 기능을 독립적으로 개발하고 검증하기도 쉬운 장점이 있습니다.

하지만 ECU가 계속 늘어나면

배선과 커넥터, 전원선과 통신망이 많아지고 여러 ECU 사이의 데이터 의존관계도 복잡해집니다.

차량 전체 소프트웨어를 업데이트하거나 통합 테스트하는 난이도도 커집니다.

도메인 아키텍처 Domain Architecture

여러 개의 ECU 기능을 큰 기능 영역별로 묶어 하나의 고성능 컴퓨터에서 처리하는 구조입니다.

대표적으로 ADAS 도메인과 차체 도메인, 인포테인먼트 도메인, 파워트레인 또는 차량제어 도메인 등을 구성할 수 있습니다.

ADAS Domain Controller

카메라와 레이더 등 여러 센서 데이터를 받아 인지와 센서퓨전, 일부 판단 기능을 고성능 프로세서에서 처리할 수 있습니다.

과거 여러 ECU에 분산되어 있던 계산을 하나의 도메인 컨트롤러로 통합할 수 있습니다.

차체 도메인

도어와 창문, 조명과 와이퍼, 시트와 공조 등 여러 차체 기능을 통합 관리할 수 있습니다.

인포테인먼트 도메인

디지털 계기판과 내비게이션, 미디어와 스마트폰 연동 등 사용자 경험과 관련된 기능을 통합할 수 있습니다.

도메인을 나누면 통신이 없어질까?

아닙니다.

ADAS가 차량 속도와 조향 정보를 필요로 하고 인포테인먼트가 배터리 상태를 표시해야 하는 것처럼 도메인 사이의 데이터 교환은 계속 필요합니다.

오히려 도메인 간 고속 통신의 중요성이 커집니다.

도메인 컨트롤러 사이에는 Ethernet이 중요하다

대용량 데이터를 처리해야 하는 고성능 컴퓨터 사이에서는 Automotive Ethernet을 백본 네트워크로 사용하는 방향이 확대되고 있습니다.

CAN과 LIN은 각 도메인의 하위 장치 연결에 계속 활용될 수 있습니다.

Backbone Network란?

차량의 여러 영역과 도메인을 연결하는 중심 통신망을 의미합니다.

사람의 몸에서 척추와 주요 신경망이 여러 부위를 연결하는 것처럼 차량 데이터가 이동하는 주요 경로라고 이해할 수 있습니다.

존 아키텍처 Zonal Architecture

도메인 아키텍처 다음 단계로 많이 논의되는 구조 가운데 하나입니다.

기능별이 아니라 차량의 물리적인 위치를 기준으로 전자장치를 묶습니다.

예를 들어 좌측 전방 존

좌측 앞쪽에 있는 헤드램프와 휠센서, 범퍼센서와 여러 액추에이터를 가까운 Zone Controller에 연결할 수 있습니다.

존 컨트롤러는 이를 중앙 컴퓨터와 고속 네트워크로 연결합니다.

존 구조의 장점

각 센서와 액추에이터를 차량 중앙까지 길게 배선하는 대신 가까운 존 컨트롤러에 연결할 수 있어 배선 구조를 단순화할 가능성이 있습니다.

차량 전체의 와이어링 하네스 무게와 복잡성을 줄이는 데 도움이 될 수 있습니다.

존 컨트롤러는 단순한 게이트웨이일까?

설계에 따라 단순 데이터 중계뿐 아니라 전원분배와 입출력 처리, 일부 실시간 제어까지 수행할 수 있습니다.

Central Computing Architecture

더 나아가 소수의 고성능 중앙 컴퓨터가 차량의 주요 소프트웨어 기능을 통합 실행하는 방향으로 발전할 수 있습니다.

여러 도메인 기능을 하나의 고성능 컴퓨팅 플랫폼에서 실행하고 하위 센서와 액추에이터는 존 컨트롤러를 통해 연결하는 구조입니다.

중앙 컴퓨터 하나가 자동차의 모든 것을 제어할까?

반드시 그렇지는 않습니다.

안전과 실시간성이 중요한 일부 제어는 별도의 MCU나 지역 제어기에서 수행할 수 있습니다.

중앙집중화의 정도는 제조사와 차량 설계에 따라 달라집니다.

왜 하드웨어와 소프트웨어를 분리하려 할까?

기능 하나가 특정 ECU와 강하게 결합되어 있으면 하드웨어를 바꿀 때 소프트웨어를 다시 수정해야 하는 범위가 커집니다.

표준화된 인터페이스를 사용하면 하드웨어가 변경되어도 상위 애플리케이션을 비교적 쉽게 유지할 수 있습니다.

Hardware Abstraction

센서와 통신장치 등 실제 하드웨어의 세부 제어를 하위 소프트웨어 계층에서 처리하고 상위 애플리케이션에는 공통된 인터페이스를 제공하는 개념입니다.

완전히 하드웨어와 무관해질 수 있을까?

아닙니다.

카메라의 해상도와 ECU의 연산 성능, 네트워크 속도처럼 실제 하드웨어의 한계는 여전히 존재합니다.

추상화의 목적은 물리적 제약을 없애는 것이 아니라 불필요한 결합을 줄이는 것입니다.

SDV Software-Defined Vehicle

자동차의 기능과 사용자 경험에서 소프트웨어가 차지하는 비중이 크게 증가하고 출고 이후에도 소프트웨어 업데이트를 통해 기능이 변화하는 자동차를 설명하는 개념입니다.

SDV에서는 데이터가 왜 중요할까?

하나의 기능이 여러 센서와 ECU의 데이터를 이용하기 때문입니다.

데이터를 표준화하고 필요한 애플리케이션에 안정적으로 전달할 수 있어야 새로운 기능을 개발하기 쉬워집니다.

Vehicle Signal Specification

차량 데이터를 표준적인 이름과 계층구조로 정의하려는 접근도 있습니다.

예를 들어 Vehicle.Speed 또는 Door 상태처럼 데이터 이름과 의미를 일관성 있게 정의하면 애플리케이션 개발이 쉬워질 수 있습니다.

데이터 이름이 왜 중요한가?

제조사와 ECU마다 같은 차량 속도를 서로 다른 이름과 단위로 표현하면 소프트웨어 재사용이 어려워집니다.

표준적인 데이터 모델은 이러한 문제를 줄이는 데 도움이 됩니다.

Data Broker의 역할

차량 데이터 브로커는 여러 곳에서 생성되는 차량 데이터를 수집하고 필요한 애플리케이션에 제공할 수 있습니다.

접근권한과 구독관계, 데이터 캐시 등을 관리하는 중간 계층 역할을 할 수 있습니다.

ADAS에서 어떻게 활용될까?

카메라와 레이더, 차량 속도와 조향각 등 다양한 데이터가 여러 계산 모듈 사이에서 전달됩니다.

각 모듈은 필요한 데이터를 정해진 인터페이스로 받아 인지와 판단, 제어 단계에서 사용할 수 있습니다.

센서 원본 데이터를 모두 공유할까?

반드시 그렇지는 않습니다.

고해상도 카메라와 라이다 데이터는 매우 크기 때문에 처리 위치와 네트워크 대역폭을 고려해야 합니다.

센서 가까이에서 먼저 처리한 객체정보나 특징정보만 다른 시스템으로 전달하는 방식도 가능합니다.

Sensor Fusion

카메라와 레이더 등 서로 다른 센서의 정보를 결합해 주변 환경을 보다 신뢰성 있게 인식하는 기술입니다.

이때 데이터의 시간 동기화와 좌표계 변환이 매우 중요합니다.

모든 센서 데이터가 같은 좌표계일까?

아닙니다.

카메라와 레이더가 차량의 서로 다른 위치와 방향에 설치되어 있기 때문에 측정값을 공통 차량 좌표계로 변환해야 합니다.

Calibration이 중요한 이유

센서가 차량의 어느 위치에 어떤 각도로 설치되어 있는지 정확하게 알아야 여러 센서의 데이터를 올바르게 합칠 수 있습니다.

장착 위치가 틀어지면 센서 퓨전 정확도가 떨어질 수 있습니다.

진단 시스템과 논리적 데이터 접근

정비소의 진단기는 차량 내부의 진단 통신을 이용해 여러 ECU의 오류코드와 상태정보를 확인합니다.

그러나 이를 하나의 진단 의사 회로망이라고 부르기보다는 표준화된 진단 프로토콜과 게이트웨이를 통해 여러 ECU에 접근한다고 설명하는 것이 정확합니다.

UDS Unified Diagnostic Services

자동차 ECU 진단에 널리 사용되는 표준 서비스 체계입니다.

고장코드 읽기와 데이터 확인, ECU 프로그래밍 등 다양한 진단 기능을 정의합니다.

DoIP Diagnostics over Internet Protocol

Ethernet과 IP 네트워크를 이용해 고속으로 차량 진단을 수행하는 기술입니다.

ECU 소프트웨어 용량이 커지면서 빠른 데이터 전송이 필요한 차량에서 중요성이 커지고 있습니다.

진단기가 ECU를 직접 하나씩 연결할 필요가 없는 이유

차량 진단 커넥터에서 중앙 게이트웨이나 Ethernet 백본을 통해 여러 ECU로 진단 요청을 전달할 수 있기 때문입니다.

하지만 내부적으로는 각 ECU별 주소와 진단 서비스가 여전히 존재합니다.

OTA Over-The-Air

차량 소프트웨어를 무선 통신으로 업데이트하는 기술입니다.

SDV에서 중요한 기능이지만 단순히 네트워크가 있다는 이유만으로 안전한 OTA가 구현되는 것은 아닙니다.

OTA에는 무엇이 필요할까?

업데이트 대상 ECU 관리와 버전 관리, 패키지 검증과 전자서명, 통신 보안과 실패 시 복구 기능 등이 필요합니다.

업데이트 중 전원이 끊기면?

ECU가 정상적으로 부팅하지 못하는 문제가 생길 수 있기 때문에 이중 파티션과 롤백, 안전한 재시도 등의 설계가 활용될 수 있습니다.

OTA와 논리적 네트워크의 관계

소프트웨어 배포 시스템은 차량의 실제 ECU 위치와 네트워크 구조를 관리하면서 적절한 대상에 업데이트를 전달합니다.

상위 관리 시스템에서는 ECU를 논리적인 소프트웨어 대상이나 서비스 단위로 관리할 수 있지만 실제 업데이트 데이터는 물리 네트워크를 통해 전달됩니다.

인포테인먼트와 차량 데이터

디지털 계기판과 인포테인먼트 시스템은 차량 속도와 주행거리, 배터리 잔량과 타이어 경고 등의 정보를 표시합니다.

이러한 데이터는 다른 차량 제어기에서 생성되므로 안전하게 전달받아야 합니다.

인포테인먼트가 브레이크 ECU를 직접 제어해도 될까?

일반적으로 그렇게 설계해서는 안 됩니다.

편의·엔터테인먼트 영역과 안전 관련 제어 영역 사이에는 강한 보안 경계와 접근제어가 필요합니다.

Network Segmentation

기능과 보안 수준에 따라 네트워크 영역을 분리하는 개념입니다.

외부 인터넷과 연결되는 인포테인먼트 영역이 안전 제어 ECU에 자유롭게 접근하지 못하도록 게이트웨이와 방화벽 정책을 적용할 수 있습니다.

자동차 사이버보안

차량이 외부와 연결될수록 통신망과 소프트웨어 공격 표면도 증가합니다.

따라서 인증과 암호화, Secure Boot와 침입탐지, 업데이트 보안 등이 중요합니다.

누구나 차량 데이터를 구독할 수 있을까?

아닙니다.

미들웨어와 데이터 브로커에서는 애플리케이션별 권한을 관리해야 합니다.

특히 위치정보와 운전자 개인정보, 안전 관련 제어 데이터는 엄격하게 제한할 필요가 있습니다.

Access Control

어떤 애플리케이션이나 ECU가 어떤 데이터를 읽거나 변경할 수 있는지를 제한하는 보안 기술입니다.

읽기 권한과 제어 권한을 분리할 수도 있습니다.

인증 Authentication

통신 상대가 정말 허가된 ECU나 소프트웨어인지 확인하는 과정입니다.

공격자가 가짜 ECU나 메시지를 삽입하는 것을 막는 데 중요합니다.

메시지 인증

특정 메시지가 변조되지 않았고 신뢰할 수 있는 송신자가 보냈음을 검증하는 보안기술을 사용할 수 있습니다.

Functional Safety와 통신

안전 기능에 사용하는 데이터는 보안뿐 아니라 오류와 고장에도 대응해야 합니다.

메시지 손실과 지연, 센서 오류를 탐지하고 필요하면 안전 상태로 전환해야 합니다.

Safety와 Security는 다르다

Functional Safety는 우발적인 하드웨어·소프트웨어 고장 때문에 위험이 발생하지 않도록 하는 개념입니다.

Cybersecurity는 의도적인 공격과 비인가 접근으로부터 시스템을 보호하는 개념입니다.

미래 차량에서는 두 영역을 함께 고려해야 합니다.

중앙집중형 차량에서 네트워크 장애가 더 위험할까?

중앙 컴퓨터에 많은 기능이 통합되면 한 부분의 고장이 여러 기능에 영향을 줄 가능성이 생길 수 있습니다.

따라서 이중화와 고장격리, 독립 전원과 네트워크 경로 등이 중요해질 수 있습니다.

Ethernet Backbone 이중화

안전 요구가 높은 시스템에서는 하나의 네트워크 경로가 끊겨도 다른 경로를 사용할 수 있는 중복 구조를 설계할 수 있습니다.

서비스가 사라지면 어떻게 할까?

Service-Oriented Architecture에서는 필요한 서비스가 갑자기 사용할 수 없게 되는 상황도 고려해야 합니다.

애플리케이션은 오류를 감지하고 대체 데이터나 안전 모드로 전환할 수 있어야 합니다.

QoS Quality of Service

네트워크 트래픽마다 필요한 우선순위와 지연시간, 대역폭 조건을 관리하는 개념입니다.

음악 스트리밍 데이터와 긴급 제어 데이터가 같은 수준으로 처리되어서는 안 됩니다.

TSN Time-Sensitive Networking

Ethernet에서 시간에 민감한 데이터를 예측 가능한 지연으로 전달하기 위한 기술군입니다.

자동차의 실시간 Ethernet 통신에서 중요한 기술로 활용될 수 있습니다.

TSN을 쓰면 CAN이 사라질까?

반드시 그렇지는 않습니다.

CAN과 LIN은 비용과 안정성 면에서 강점이 있기 때문에 단순 센서와 액추에이터 영역에서 계속 사용될 가능성이 높습니다.

Ethernet과 기존 버스가 오랫동안 공존할 수 있습니다.

미래 자동차의 통신 구조

중앙 고성능 컴퓨터와 Ethernet 백본, 여러 Zone Controller가 차량의 물리적인 장치를 연결하고 상위 소프트웨어에서는 서비스와 데이터 중심 인터페이스를 이용하는 구조가 확대될 가능성이 있습니다.

소프트웨어 개발자가 얻는 장점

차량 속도 데이터가 실제 어느 ECU에서 생성되는지를 매번 직접 처리하지 않고 표준화된 데이터 인터페이스를 이용할 수 있습니다.

이를 통해 애플리케이션 재사용성과 개발속도를 높일 수 있습니다.

자동차 제조사가 얻는 장점

차량 플랫폼이 달라져도 소프트웨어 인터페이스를 일정하게 유지하면 여러 차종에서 기능을 재사용하기 쉬워질 수 있습니다.

OTA를 이용한 기능 개선과 유지관리에도 유리합니다.

하지만 소프트웨어만 바꾸면 무엇이든 가능할까?

아닙니다.

센서와 액추에이터, 프로세서 성능과 전력·열설계 등 실제 하드웨어가 기능을 지원해야 합니다.

SDV라는 개념 역시 하드웨어의 중요성을 없애는 것이 아닙니다.

데이터 중심 차량의 또 다른 과제

차량 전체에서 데이터가 많아지면 어떤 데이터가 정확한 최신 값인지와 누가 사용할 수 있는지를 체계적으로 관리해야 합니다.

Single Source of Truth

같은 차량 속도 정보가 여러 ECU에서 서로 다른 값으로 존재하면 소프트웨어가 혼란스러울 수 있습니다.

권위 있는 데이터 소스와 명확한 데이터 정의를 만드는 것이 중요합니다.

데이터 신뢰도도 전달할 수 있다

센서 값뿐 아니라 값이 유효한지와 오류 상태가 있는지, 측정된 시간이 언제인지 등의 메타데이터를 함께 제공할 수 있습니다.

자율주행에서는 특히 중요하다

단순히 물체가 앞에 있다는 정보만 받는 것이 아니라 해당 정보의 신뢰도와 갱신 시간, 센서 상태를 함께 판단해야 안전한 결정을 할 수 있습니다.

차량 내부 네트워크의 미래는 하나의 기술로 통일될까?

가능성이 높다고 단정하기 어렵습니다.

고속 컴퓨팅 영역은 Ethernet 중심으로 발전할 수 있지만 비용이 중요한 로컬 센서와 액추에이터에는 CAN과 LIN 같은 기술이 계속 적합할 수 있습니다.

결국 중요한 것은 계층화

각 기술이 자신의 역할을 담당하고 상위 소프트웨어가 공통 인터페이스를 통해 이를 사용할 수 있도록 만드는 구조가 중요합니다.

이러한 계층화와 추상화가 원문에서 말한 의사 회로망의 핵심 의미와 가장 가까운 설명입니다.

자동차 네트워크 발전 흐름

• 개별 부품의 일대일 배선
• CAN과 LIN 등 공용 통신 버스 확대
• 중앙 게이트웨이를 통한 네트워크 통합
• 기능별 Domain Controller 도입
• Automotive Ethernet 백본 확대
• Zonal Architecture와 중앙 컴퓨팅 도입
• AUTOSAR와 미들웨어를 통한 통신 추상화
• SOA와 Publish-Subscribe 기반 데이터 공유
• SDV와 차량 데이터 브로커 중심 구조 발전

FAQ

도메인 컨트롤러란 무엇인가요?

여러 ECU의 기능을 ADAS, 차체, 인포테인먼트 등 기능 영역별로 통합해 처리하는 고성능 전자제어장치입니다.

Zone Controller는 무엇이 다른가요?

기능 종류보다 차량의 물리적 위치를 기준으로 가까운 센서와 액추에이터를 연결하고 중앙 컴퓨터와 통신하는 구조입니다.

SDV에서는 모든 차량 데이터가 중앙 컴퓨터에 모이나요?

반드시 그렇지는 않습니다. 실시간성과 데이터량에 따라 로컬 제어기나 도메인, 존 컨트롤러에서 먼저 처리하고 필요한 정보만 중앙 시스템으로 전달할 수 있습니다.

OTA는 AUTOSAR 기능인가요?

AUTOSAR가 OTA 구현에 필요한 일부 소프트웨어 기반을 제공할 수 있지만 OTA 전체는 업데이트 관리 서버와 통신, 보안, ECU 프로그래밍과 복구기능 등이 함께 필요한 별도의 시스템입니다.

진단 의사 회로망이라는 별도 네트워크가 있나요?

일반적으로 그렇게 부르는 표준 네트워크는 없습니다. 실제 차량 진단에는 UDS와 DoIP, CAN 등의 표준 통신 기술과 중앙 게이트웨이가 사용됩니다.

Ethernet이 앞으로 CAN을 완전히 대체하나요?

그렇게 단정하기 어렵습니다. 고속 데이터 영역에서는 Ethernet이 확대되지만 비용과 단순성이 중요한 장치에서는 CAN과 LIN이 계속 사용될 가능성이 높습니다.

SDV에서는 소프트웨어만 바꾸면 새 기능을 모두 추가할 수 있나요?

아닙니다. 필요한 센서와 액추에이터, 연산 성능과 전기·전자 하드웨어가 이미 지원되어야 소프트웨어 기능을 구현할 수 있습니다.

의사 회로망 개념이 미래 자동차에서 중요한 이유는 무엇인가요?

실제 네트워크와 ECU 위치의 복잡성을 상위 애플리케이션에서 숨기고 데이터와 서비스를 표준화하면 기능 개발과 재사용, OTA와 플랫폼 확장을 보다 쉽게 만들 수 있기 때문입니다.

현대 자동차에는 엔진과 변속기, 브레이크와 에어백, 공조장치와 인포테인먼트, 첨단 운전자 보조 시스템까지 수많은 전자제어장치가 들어 있습니다.

이 장치들은 각자 독립적으로 작동하는 것처럼 보이지만 실제로는 서로 많은 정보를 주고받아야 합니다. 예를 들어 차량 속도 정보는 계기판뿐 아니라 내비게이션과 변속기 제어, 일부 ADAS 기능에서도 활용될 수 있습니다.

문제는 모든 ECU를 서로 직접 연결하면 배선과 통신구조가 지나치게 복잡해진다는 점입니다. 그래서 자동차에서는 CAN과 LIN, Automotive Ethernet 같은 공용 통신망을 사용하고, 그 위에 미들웨어와 데이터 추상화 계층을 두어 필요한 정보를 논리적으로 공유하는 방향으로 발전해왔습니다.

일부 설명에서는 이러한 구조를 의사 회로망 또는 Pseudo-Network라고 표현하기도 하지만, 자동차 산업에서 널리 통용되는 하나의 정식 표준 명칭이라기보다는 물리적인 연결을 숨기고 논리적으로 하나의 네트워크처럼 보이게 하는 개념적 표현으로 이해하는 것이 더 정확합니다.

자동차에는 왜 이렇게 많은 ECU가 있을까?

ECU Electronic Control Unit는 차량의 특정 기능을 전자적으로 제어하는 컴퓨터입니다.

과거에는 엔진 제어기나 변속기 제어기처럼 기능별로 독립된 ECU가 추가되면서 차량 내 ECU 수가 빠르게 늘어났습니다.

차량에 따라 수십 개에서 그보다 훨씬 많은 전자제어장치가 존재할 수 있습니다.

ECU는 서로 어떤 정보를 주고받을까?

대표적으로 차량 속도와 엔진 회전수, 조향각과 브레이크 상태, 도어 상태, 배터리 전압과 온도 등 다양한 정보를 공유합니다.

한 ECU가 만든 정보가 여러 다른 ECU에서 동시에 필요할 수 있습니다.

모든 ECU를 일대일로 연결하면 어떻게 될까?

예를 들어 20개의 ECU가 서로 모두 직접 통신해야 한다면 엄청난 수의 배선과 커넥터가 필요해질 수 있습니다.

차량 무게와 비용이 증가하고 고장 가능성과 정비 복잡성도 커집니다.

이를 해결하기 위해 여러 ECU가 하나의 통신선을 공유하는 버스 네트워크가 도입되었습니다.

자동차 통신 버스란?

여러 전자제어장치가 공통 통신선을 이용해 데이터를 주고받는 구조입니다.

각 ECU가 필요할 때 메시지를 전송하고 다른 ECU는 해당 메시지를 받아 필요한 정보를 사용합니다.

CAN Controller Area Network

CAN은 자동차에서 가장 대표적으로 사용되어온 차량 내부 통신 방식 가운데 하나입니다.

두 가닥의 차동 신호선을 통해 여러 ECU가 같은 버스를 공유할 수 있습니다.

CAN에서는 누구에게 메시지를 보내는 것일까?

전통적인 CAN에서는 특정 ECU 주소에 직접 메시지를 보내는 방식보다 메시지 식별자 ID를 중심으로 통신합니다.

각 ECU는 자신에게 필요한 CAN ID를 수신해 데이터를 사용합니다.

CAN의 장점

구조가 비교적 단순하고 노이즈에 강하며 우선순위 기반의 메시지 중재가 가능해 자동차 제어에 적합합니다.

엔진과 변속기, 차체 제어 등 여러 시스템에서 오랫동안 사용되어왔습니다.

LIN Local Interconnect Network

LIN은 CAN보다 낮은 속도와 저렴한 비용이 필요한 장치에 사용하는 통신 방식입니다.

도어 모터와 시트, 미러와 공조 플랩처럼 비교적 단순하고 데이터량이 많지 않은 장치에서 활용될 수 있습니다.

왜 모든 곳에 CAN을 쓰지 않을까?

통신속도가 높고 기능이 많을수록 일반적으로 비용과 회로 복잡성이 증가할 수 있습니다.

따라서 요구 성능이 낮은 장치에는 LIN 같은 저비용 네트워크를 사용하는 것이 효율적일 수 있습니다.

Automotive Ethernet

카메라와 고성능 컴퓨터, 인포테인먼트와 ADAS처럼 대용량 데이터를 처리해야 하는 기능이 늘면서 Automotive Ethernet의 중요성이 커졌습니다.

기존 CAN보다 훨씬 높은 데이터 전송속도를 구현할 수 있다는 장점이 있습니다.

자동차 Ethernet은 가정용 LAN과 똑같을까?

기본적인 Ethernet 기술을 기반으로 하지만 자동차 환경에 맞춘 물리계층과 프로토콜, 시간 동기화와 보안 등의 추가 요구사항이 존재합니다.

진동과 온도, 전자기 간섭이 큰 자동차 환경에서도 안정적으로 작동해야 합니다.

FlexRay는 무엇일까?

FlexRay는 높은 신뢰성과 시간 결정성이 필요한 자동차 제어를 위해 개발된 통신 기술입니다.

일부 고급 차량의 섀시와 제어시스템 등에 사용되어왔지만 최근에는 고속 Ethernet과 다른 기술이 확대되면서 적용 환경이 변화하고 있습니다.

한 자동차에 여러 네트워크가 공존한다

실제 차량에서는 CAN 하나만 사용하는 것이 아닙니다.

여러 CAN 버스와 LIN, Ethernet 등의 네트워크가 동시에 존재할 수 있습니다.

각 네트워크는 속도와 비용, 안전 요구조건에 맞춰 서로 다른 기능을 담당합니다.

서로 다른 네트워크는 어떻게 연결할까?

이때 사용하는 대표적인 장치가 Gateway입니다.

게이트웨이는 한 네트워크에서 받은 정보를 다른 네트워크로 전달하거나 필요한 경우 메시지 형식을 변환합니다.

게이트웨이는 단순한 전선 연결 장치일까?

아닙니다.

메시지 라우팅과 필터링, 보안 정책과 진단 통신, 때로는 프로토콜 변환까지 수행할 수 있는 전자제어장치입니다.

예를 들어보면

엔진 ECU가 CAN에서 차량 속도 정보를 보내고 인포테인먼트 시스템이 Ethernet 영역에 있다고 가정할 수 있습니다.

게이트웨이가 필요한 차량 속도 정보를 CAN 영역에서 받아 다른 네트워크 영역으로 전달할 수 있습니다.

그렇다면 의사 회로망은 무엇일까?

여기서부터는 물리적인 네트워크와 논리적인 네트워크를 구분해서 생각하면 이해하기 쉽습니다.

물리적으로는 차량 속도 데이터가 특정 CAN 버스를 지나 게이트웨이를 거쳐 Ethernet으로 전달될 수 있습니다.

하지만 애플리케이션은 이러한 세부 경로를 모두 알 필요 없이 단순히 차량 속도 데이터라는 논리적 인터페이스를 통해 값을 받을 수 있습니다.

이러한 구조를 통신 추상화라고 한다

Abstraction은 복잡한 내부 구조를 숨기고 필요한 기능만 단순한 인터페이스로 제공하는 것을 의미합니다.

자동차 소프트웨어에서는 하드웨어와 네트워크 구조를 추상화해 애플리케이션 개발자가 기능에 집중할 수 있도록 합니다.

의사 회로망이라는 말보다 더 정확한 표현

상황에 따라 Virtual Network와 Logical Network, Communication Abstraction, Data Abstraction, Middleware, Service-Oriented Communication 등의 표현이 더 적절할 수 있습니다.

구체적으로 어떤 기술을 설명하느냐에 따라 용어를 구분하는 것이 중요합니다.

논리 네트워크 Logical Network

실제 배선이 어떻게 되어 있는지와 관계없이 특정 기능이나 데이터 흐름을 하나의 논리적 네트워크로 묶어 관리하는 개념입니다.

가상 LAN인 VLAN도 넓은 의미에서 물리 네트워크 위에 논리적인 구분을 만드는 기술입니다.

VLAN은 자동차에서도 사용할 수 있을까?

Ethernet 기반 자동차 네트워크에서는 VLAN을 이용해 트래픽을 논리적으로 분리할 수 있습니다.

예를 들어 서로 다른 기능의 통신을 구분하고 네트워크 정책을 적용하는 데 활용할 수 있습니다.

VLAN과 의사 회로망은 같은 것일까?

동일한 개념이라고 볼 수는 없습니다.

VLAN은 Ethernet 네트워크에서 실제로 정의된 구체적인 표준 기술이고 의사 회로망이라는 표현은 훨씬 넓고 모호한 추상적 개념에 가깝습니다.

미들웨어 Middleware란?

운영체제나 통신계층과 실제 애플리케이션 사이에서 데이터 전달과 서비스 호출을 중개하는 소프트웨어 계층입니다.

애플리케이션이 CAN ID나 Ethernet 패킷 같은 세부사항을 일일이 처리하지 않아도 되도록 합니다.

메신저 비유로 이해하기

메신저 사용자는 상대방이 Wi-Fi를 쓰는지 LTE를 쓰는지, 데이터가 어떤 라우터를 거치는지 몰라도 메시지를 보낼 수 있습니다.

애플리케이션은 메시지 보내기라는 기능만 사용하고 아래의 복잡한 통신 과정은 운영체제와 네트워크 계층이 처리합니다.

자동차 미들웨어도 비슷한 역할을 할 수 있습니다.

AUTOSAR란 무엇일까?

AUTOSAR Automotive Open System Architecture는 자동차 전자·소프트웨어 아키텍처를 표준화하기 위한 국제적인 협력체이자 표준 플랫폼입니다.

소프트웨어 컴포넌트와 통신, 진단, 운영체제 등 다양한 부분의 표준 인터페이스를 제공합니다.

AUTOSAR Classic Platform

주로 임베디드 ECU에서 높은 실시간성과 결정성이 필요한 제어 애플리케이션을 지원하는 구조입니다.

엔진과 섀시, 차체 제어 등 기존 ECU 환경에서 널리 활용됩니다.

AUTOSAR Adaptive Platform

고성능 컴퓨팅과 동적인 서비스 실행이 필요한 차세대 차량을 위한 플랫폼입니다.

ADAS와 자율주행, 중앙 컴퓨팅 등과 같은 고성능 시스템에서 활용할 수 있도록 설계되었습니다.

RTE Runtime Environment

AUTOSAR Classic에서는 애플리케이션 소프트웨어 컴포넌트가 서로 통신하고 하위 시스템과 연결될 수 있도록 RTE가 중간 계층 역할을 합니다.

애플리케이션은 실제 데이터가 어느 CAN 메시지를 통해 들어오는지 세부사항을 직접 처리하지 않아도 됩니다.

이것이 원문에서 말한 의사 회로망과 가장 가까운 개념일 수 있다

실제 차량에서는 하나의 Pseudo-Network라는 시스템이 존재한다기보다 이러한 RTE와 미들웨어, 데이터 라우팅과 서비스 계층이 물리적인 통신 구조를 추상화합니다.

메시지 중심 통신

전통적인 차량 통신에서는 특정 메시지에 여러 신호를 담아 주기적으로 전송하는 방식이 많이 사용됩니다.

CAN에서 차량 속도와 엔진 회전수 등을 정해진 메시지 ID로 보내는 방식이 대표적입니다.

Signal이란?

CAN 프레임 같은 하나의 메시지 안에 들어가는 실제 정보 단위를 Signal이라고 부를 수 있습니다.

예를 들어 하나의 메시지 안에 차량 속도와 브레이크 상태 등이 정해진 비트 위치에 들어갈 수 있습니다.

개발자는 모든 비트 위치를 알아야 할까?

하위 계층에서는 정확한 데이터 정의가 필요하지만 애플리케이션 개발자에게는 이를 추상화된 변수나 인터페이스 형태로 제공할 수 있습니다.

이것이 소프트웨어 계층화의 큰 장점입니다.

Service-Oriented Architecture

차량 기능이 복잡해지면서 단순히 메시지를 계속 방송하는 방식뿐 아니라 필요한 기능을 서비스 형태로 제공하는 구조가 중요해지고 있습니다.

이를 Service-Oriented Architecture, SOA라고 합니다.

서비스라는 것은 무엇일까?

예를 들어 차량 위치를 제공하는 서비스와 도어 상태를 제공하는 서비스, 진단 서비스를 각각 독립적인 기능 단위로 정의할 수 있습니다.

다른 애플리케이션은 필요할 때 해당 서비스를 찾고 데이터를 요청하거나 구독할 수 있습니다.

Publish-Subscribe 방식

데이터를 생성하는 쪽이 Publisher가 되고 해당 정보가 필요한 쪽이 Subscriber가 되는 통신 방식입니다.

Subscriber는 데이터가 어느 물리적 센서나 ECU에서 만들어졌는지보다 어떤 Topic 또는 Service를 구독할 것인지에 집중할 수 있습니다.

차량 속도를 예로 들면

휠 속도와 다른 정보를 바탕으로 차량 속도를 계산하는 ECU가 값을 생성합니다.

계기판과 내비게이션, ADAS 등이 차량 속도 정보를 각각 사용할 수 있습니다.

서비스 또는 데이터 중심 구조에서는 하나의 데이터 제공자가 여러 소비자에게 정보를 배포할 수 있습니다.

SOME/IP란?

SOME/IP Scalable service-Oriented MiddlewarE over IP는 자동차 Ethernet 환경에서 서비스 지향 통신을 구현하는 데 사용되는 대표적인 기술 가운데 하나입니다.

서비스 발견과 메서드 호출, 이벤트 통신 등을 지원할 수 있습니다.

Service Discovery

어떤 서비스가 현재 네트워크 어디에서 제공되고 있는지를 찾는 기능입니다.

이를 이용하면 애플리케이션이 특정 ECU 주소를 하드코딩하기보다 필요한 서비스를 동적으로 찾는 구조를 만들 수 있습니다.

차량 데이터 브로커

최근 SDV에서는 여러 차량 데이터를 한곳에서 수집하고 필요한 애플리케이션에 제공하는 Vehicle Data Broker 개념도 중요해지고 있습니다.

데이터 이름과 단위를 표준화하면 애플리케이션이 ECU별 통신 구조를 직접 알 필요를 줄일 수 있습니다.

데이터 브로커가 모든 데이터를 복사할까?

반드시 그렇지는 않습니다.

필요한 데이터를 캐시하거나 중계하고 접근권한을 관리하는 등 다양한 방식으로 구현할 수 있습니다.

데이터 추상화의 실제 장점

애플리케이션이 차량 속도를 필요로 할 때 이 값이 CAN 1번 버스에서 왔는지 Ethernet 영역의 다른 ECU에서 왔는지를 몰라도 사용할 수 있습니다.

하드웨어가 변경되더라도 데이터 인터페이스를 유지할 수 있다면 상위 소프트웨어의 수정 범위를 줄일 수 있습니다.

하지만 완전히 자유로운 것은 아니다

자동차 소프트웨어는 안전과 실시간성이 중요하기 때문에 데이터 지연시간과 주기, 신뢰도와 장애 상태를 정확히 정의해야 합니다.

단순히 값을 가져올 수 있다는 것만으로 충분하지 않습니다.

Latency 지연시간

센서에서 데이터가 생성된 뒤 다른 ECU에서 실제 사용할 수 있을 때까지 걸리는 시간을 의미합니다.

안전 관련 제어에서는 매우 작은 지연과 예측 가능한 통신시간이 중요합니다.

Jitter란?

데이터 전달 시간이 매번 일정하지 않고 흔들리는 정도를 의미합니다.

실시간 제어에서는 평균 속도뿐 아니라 지터가 작은 것도 중요합니다.

시간 동기화

카메라와 레이더 같은 여러 센서 데이터를 합치려면 각각의 데이터가 언제 측정됐는지 정확하게 알아야 합니다.

차량 Ethernet에서는 정밀한 시간 동기화를 위한 기술이 사용될 수 있습니다.

센서 퓨전에서 특히 중요하다

카메라가 10시 0분 0.100초에 본 물체와 레이더가 훨씬 다른 시점에 측정한 물체를 그대로 합치면 위치가 맞지 않을 수 있습니다.

따라서 각 데이터의 Timestamp를 정확하게 관리해야 합니다.

ADAS의 실시간 제어는 중앙 데이터 풀만 보면 될까?

그렇게 단순하지 않습니다.

안전과 직결되는 기능은 정해진 지연시간 안에 데이터를 전달하고 고장 상황에서도 동작하도록 엄격하게 설계해야 합니다.

논리적 추상화가 실시간 안전 요구를 대신하지는 않습니다.

비상 제동 명령을 아무 서비스에서 보내도 될까?

아닙니다.

제동과 조향 같은 안전 관련 기능에는 엄격한 접근권한과 기능 안전, 인증된 통신 경로가 필요합니다.

일반 애플리케이션이 임의로 안전 액추에이터를 제어하도록 허용해서는 안 됩니다.

FAQ

자동차 의사 회로망이란 무엇인가요?

자동차 업계의 하나의 고정된 표준 기술명이라기보다 물리적 네트워크의 복잡성을 숨기고 데이터와 기능을 논리적으로 연결하는 통신 추상화 개념으로 이해하는 것이 적절합니다.

CAN과 의사 회로망은 같은 것인가요?

아닙니다. CAN은 실제 차량 내부에서 사용하는 표준 통신 버스이며 의사 회로망은 여러 실제 네트워크 위에 논리적 통신 구조를 만드는 개념에 가깝습니다.

게이트웨이는 무엇을 하나요?

서로 다른 CAN 버스나 Ethernet 등의 네트워크 사이에서 데이터를 라우팅하고 필요하면 메시지 변환과 보안 제어 등을 수행합니다.

AUTOSAR는 통신망인가요?

아닙니다. 자동차 소프트웨어 아키텍처와 인터페이스를 표준화하는 플랫폼이며 CAN이나 Ethernet 같은 실제 통신 기술 위에서 동작할 수 있습니다.

애플리케이션은 CAN ID를 몰라도 되나요?

소프트웨어 아키텍처에 따라 상위 애플리케이션은 미들웨어와 RTE 등을 통해 추상화된 데이터 인터페이스를 사용할 수 있습니다. 하위 계층에서는 실제 CAN 메시지와 매핑 정보가 여전히 필요합니다.

SOME/IP는 무엇인가요?

IP 기반 자동차 네트워크에서 서비스 지향 통신을 구현하는 데 활용되는 미들웨어 기술 가운데 하나입니다.

차량 데이터를 모두 하나의 중앙 서버에 모으나요?

반드시 그렇지는 않습니다. 아키텍처에 따라 각 도메인이나 중앙 컴퓨터, 데이터 브로커가 데이터를 분산 관리할 수 있습니다.