자동차 안에서 전자 분야는 담당 시스템에 따라 분야가 크게 달라집니다. 흔히 잘 알고 계시는 파워트레인과 샤시 분야 외에도 환경차분야와 자율주행분야, 전통적인 전자편의분야, 인포테인먼트 등등으로 나뉘고 각 분야별로 실제 수행하는 업무의 범위나 깊이가 매우 많이 달라요. 실제로 직접 양산 코딩까지 하는 곳도 있고 사양 정도만 만들어서 협력사에서 코드화 하는 경우도 있고 아예 요구사항 정도만 주고 실제 개발은 다 맡기는 경우도 있죠. 범위가 너무 넓어서 구체적으로 답변 드리기가 어렵네요.. 제가 담당하는쪽 아니면 저도 잘 모르기도 하구요... autosar도 양산 플랫폼 적용은 오트론에서 담당하고는 있지만 자동차 내에도 같이 플랫폼 개발하는 부서도 있습니다. 분야를 한정해서 좀 더 구체적인 질문을 주시면 계속 답변을 드릴게요 :)

상세한 답변 감사합니다!!
추가적으로 현재 ADAS/자율주행 제어기 모듈 개발로 관심이 있는데요, 앞서 말씀하셨듯이 현대차에 최적화 된 AUTOSAR기반 플랫폼을 현대자동차에서도 만든다고 하셨는데, ADAS나 자율주행 제어기 모듈도 현대자동차에서 같이 개발 중인지 궁금합니다!
그리고 이와 같은 제어기를 개발할 때 Simulink & Matlab을 사용하는지요..??
마지막으로 제어기 모듈이라고 하면, ADAS제어기 자율주행 제어기 두개로 나뉘며 그 구조가 다른 것 같았습니다. ADAS가 자율주행의 한 부분이라고 생각했는데 둘이 어떤점이 다른지 궁금합니다!!

1. 일단 autosar 플랫폼은 mcu 기반 제어기 위에 올리는플랫폼이고 유럽 회사들 중심으로 개발된 일종의 표준 소프트웨어 플랫폼입니다. 근데 이게 전체족인 틀을 잡는 규격만 있는거라 이런저런 회사들이 만들어서 팔고 있죠. (vector나 elektrobit 같은 회사가 유명합니다) 오트론도 이런 autosar 플랫폼 공급 업체 중에 하나이고 현대차 중심으로 개발하다보니 표준 규격 외에 현대차 특화 기능들이 붙어있죠. 한동안은 일부 제어기에 대해서는 현대차에서 오트론 플랫폼 사용을 강제하기도 했구요. 그래서 이 플랫폼은 오트론이 개발하지만 전체적인 방향의 리딩은 현대차에서 합니다. 일종의 공동 개발 같은 형태죠.
2. 제어기 라는 말은 꼭 자율주행 분야에만 쓰는 말은 아닙니다. mcu나 ap 들어가고 이런저런 sw 얹어서 돌아가는 모듈은 다 제어기라고 불러요. 기준이 조금 모호하긴 한데... 보통 제네시스급 차량엔 80~100개 이상의 제어기가 들어갑니다.
3. adas 제어기와 자율주행 제어기는 같은 의미입니다 (적어도 현차 내에서는요) 다만 adas 관련 제어기가 하나만 있는건 아니구요. 디테일한 시스템 구조를 알려드리긴 좀 어렵네요...^^;; 이쪽 제어기는 당연히 현차 내에서도 개발 합니다. 아마 일부 로직은 자체 개발해서 쓰고 또 일부 로직은 협력사 로직 가져다 쓰고 그럴거에요. 워낙 다양한 기술이 액티브하게 개발되는 분야라 ai 라던가 뭐 다양한 시도도 하고 그러는걸로 알고 있습니다. 시뮬링크 당연히 많이 사용하구요 (제어로직 개발의 꽃....). 시뮬링크는 자율주행 말고도 연구소 전체적으로 많이 쓰여요. 저도 맨날 라이센스 부족하다고 난리.........
4. 혹시 이걸 연관지어 생각하고 있는지 모르겠는데 adas제어기에 autosar가 올라가느냐... 라고 한다면 반은 맞고 반은 틀립니다. 일단 지금 쓰는 autosar는 classic autosar 라고 해서 osek이라는 os를 기반으로 하고 있고, 요놈은 mcu 위에서 돌아갑니다. 근데 요즘 나오는 고성능 제어기들은 다들 ap를 써요. adas 분야 최강자 nvidia 솔루션도 ap가 들어가죠. 여기다가는 autosar 보다는 리눅스나 qnx 같은 posix 계열 os를 올립니다. 그래서 posix os 대응 가능한 adaptive autosar라는걸 열심히 유럽에서 표준 제정하고 있는데... 맨날 일정이 밀리네요 ㅎㅎ

정말 상세한 답변 감사드립니다..! 현재 이 분야에 대해 궁금한 정보를 얻기가 매우 힘들었는데 정말 감사드립니다.
추가적인 질문이 있습니다(계속 질문드려 죄송할 따름입니다)

1. 관련 직무에 대해 '시스템 통합제어 -제어기 모듈 개발' 이렇게 구체화 하려고 하는데 올바른 표현인가요? 즉, 제가 생각하고 있는 Simulink를 통해 컴포넌트들을 연결시키 고 최적화를 하는 과정이 제어 모듈(?)혹은 아키텍쳐나 플랫폼 개발 이라고 하는 것이 올바를까요? (왠지 소프트웨어 reuse를 위해 하드웨어와 소프트웨어를 분리시키는 것만 플랫폼이라고 칭하는게 맞는거 같은데 라는 생각입니다) 제어로직과 제어기 모듈 개발의 차이를 알고 싶습니다!

2. '현대차에 최적화 된 Autosar 표준 소프트웨어를 적용하여 까다로운 요구조건인 iso26262를 만족시키기 위해 최적의 시스템을 설계' 와 관련된 시스템 설계도 현대차에서 하는게 맞는지요? (ASIL 분할이나 Memory partition 등으로 알고 있는데 이 과정을 직접하는 건가요..?)

3. 물론 현대에 자동차에 많은 반도체가 들어가기 때문에 차량용 시스템 반도체 및 고성능의 메모리 반도체가 필요할 것 같습니다. 사실 제가 반도체 연구실에서 소자를 설계하고 특성을 분석하는 경험이 있는데요, 제어기 모듈 개발에 있어서 고성능의 SOC나 GPU같은 컴포넌트들을 잘 이해하고 설계하는데 직접적인 직무연관적 관련이 있을까요..??

4. (질문이 많아져서 죄송합니다..ㅠㅠ) 마지막으로, 프로젝트로 영상처리를 한 경험이 있습니다. 물론 자동차에는 영상처리를 통해 주변을 인식하고 판단해야 한다는 점에서 중요하지만, 위와 같이 제어기 모듈을 개발하는데 현대자동차에서 카메라나 레이더 하나하나에 직접 코딩을 할 것 같지는 않습니다.(아닌가요 ㅠ) 카메라와 레이더 등의 여러가지 신호를 통합하는 제어 측면에서 활용이 가능한건가요..?

질문이 많아 죄송합니다. 감사합니다!

각 질문에 대한 답변에 앞서 일단 자동차 업계 돌아가는 구조를 간략하게 설명드릴 필요가 있을 것 같네요.
자동차라는게 워낙 거대하고 복잡한 시스템의 총합이고 여기에는 각 센서/액츄에이터 등 말단부터 이런 것들이 HW, SW적으로 통합된 시스템, 그리고 최종적으로는 이런 시스템들이 유기적으로 돌아가는 전체 차량 레벨까지 굉장히 다양한 깊이와 넓이의 일들이 복잡하게 얽혀있습니다. 따라서 특정 회사의 특정 조직, 특정 인원이 독립적으로 뭔가를 꾸려 나가기는 어렵고 굉장히 다양한 회사들이 다양한 역할을 상호 유기적으로 수행하게 됩니다. 자율주행이라는 카테고리만 해도 어마무지하게 큰 범위이며 여기에는 말단의 각 센서, 레이더 등을 개발하는 부품사와 이들을 조합하고 제어하는 모듈 업체, 이런 모듈에 대한 요구사항을 도출하고 각 모듈 간 유기적인 동작을 구성하는 자동차 업체까지 얽혀서 함께 결과를 도출해야하고, 여기에 HW개발 SW개발을 분리하고 SW개발도 플랫폼단과 미들웨어단, 어플리케이션 단을 구분하면 개발 주체가 또 나뉩니다. 평가/검증까지 들어가면 더 복잡해지죠. 업무의 깊이와 범위도 딱 구분된건 아니고 어떤 시스템은 차량 제조사가 SW 개발까지 하는 경우도 있고 또 어떤 시스템은 차량 제조사는 대략적인 요구사항만 내고 나머지는 다 개발 업체가 알아서 하는 경우도 있습니다. 뭐라고 딱 하나의 케이스로 정형화 하기가 어렵죠.
“일반적”으로는 자동차 회사에서는 전체적인 시스템 구성을 위한 요구사항을 도출하고, 일부 중요 핵심 로직을 개발하는 정도의 역할을 주로 수행합니다. 이게 문제 났을 때 책임소재도 있고 해서 웬만하면 직접 핸드코딩하고 설계하고 하는 경우는 피하려고 해요. 저도 사실 ADAS 쪽은 한다리 건너 아는 정도라 정확하게 어떻게 돌아가는지는 모르기 때문에 “일반적인” 범주에서 설명 드릴게요. 실제와는 좀 다를 수 있습니다.

1. 일단 사용하신 용어가 좀 모호하긴 합니다. 사람마다 조직마다 분야마다 같은 말을 미묘하게 다른 의미/깊이로 사용하고 있어서.. 제어 로직 개발은 말 그대로 어떤 기능이 어떻게 동작해야 하는가를 개발하는겁니다. 좀 더 어플리케이션 레벨에 가까워요. 주로 simulink로 개발하는 경우가 많은걸로 알고 있고(정확하진 않습니다) 이걸 코드 레벨로 구현하는건 또 다른 얘기입니다. 예를 들어 자율주행 중에 LFA(Lane Following Assist)라는 차선 유지 조향 보조 기능이 있는데, 이 기능의 제어 로직이라면 어떤 센서의 어떤 정보가 어떻게 조합되었을 때 이를 제어기하 위해서 steering을 어떻게 움직여야 하는가를 정의하는거죠. 실제 구현 레벨 앞단의 logical한 구성을 의미합니다.
제어기 모듈 개발이라고 하면 일단 느낌으로는 좀 더 실제 구현에 가까운 느낌이네요. 제어기라는건 일종의 아주 작은 (경우에 따라서는 꽤 큰) 임베디드 시스템이고, 여기에는 앞서 얘기한 다양한 제어 로직들이 “개별 기능” 으로써 포함됩니다. 어플리케이션에 가깝죠. 하지만 실제 제어기 구현을 위해서는 이런 기능들이 유기적으로 동작하기 위한 datapath 구성부터 해서 미들웨어 단의 각종 HW 드라이버들, 전원 체계 관리 및 메모리 관리, 소모전류 관리, 동작 모드 관리 및 각 모드에서 기능 동작 수준 정의, 타 제어기와의 통신 관리, 진단 및 업데이트 대응, 보안 대응 등등등 비 기능적인 요소들이 엄청 많죠.
아키텍처/플랫폼이란 말도 굉장히 다양하게 사용됩니다만, 이를 제어기 내부로 한정해서 생각해보면 아키텍처는 내부 소프트웨어 구조에서 각 기능 모듈 별 역할을 어디까지로 한정하고, 어떤 역할을 미들웨어로 정의하고 어플리케이션으로 정의할지, 모듈 간 데이터 전달은 어떻게 할지 등을 정의하는 내용이겠네요. 플랫폼은 말 그대로 AUTOSAR 같은 플랫폼을 의미하는 경우가 많고 이건 그냥 만들어져 있는 플랫폼을 적당히 가져다 쓰는 걸로 해결합니다. 제어기 개발하는 사람이 디테일한 신경을 쓰진 않아요.

2. ISO26262는 정의하고 있는 범위가 어마무지합니다. 고장 위험 분석부터 이를 대비하기 위한 HW SW 구성 및 생산 과정까지 요구하는 내용이 있고 각 과정 별 문서화까지 철저하게 요구합니다. 그래서 연구소 내에 기능안전 대응 전담 조직도 있어요. ASIL 분할이랑 memory partition은 레벨이 좀 다른 얘긴데, ASIL 분할은 높은 등급의 1가지 요소를 낮은 등급 2가지로 분할해서 “빡센 대책 하나 보다 좀 쉬운 대책 여러가지로 땜빵하자” 라는 일종의 방법론이구요, memory partition 같은건 이미 정해진 등급을 만족하기 위한 실제적인 실천 방법 중에 하나 정도로 생각할 수 있겠네요. AUTOSAR 표준이 일정 부분 26262 대응을 해주는 부분이 있는건 사실인데 이를 위한 AUTOSAR 개발 자체는 아마 오트론에서 할거구요, 이걸 포함한 전체 시스템의 26262 기준 만족을 위한 각종 개발 활동은 연관된 모든 개발사에서 공동으로 하는 부분입니다.

3. 당연히 모든 개발 경험은 도움이 됩니다. 특히 반도체는 차량 전장의 핵심 근간이 되므로.. 뭘 어떻게 해도 엮일 수 밖에 없죠. 근데 그 설계 경험이 직접적인 연관성이 있느냐.. 라고 하면 좀 다른 얘기긴 합니다. 이미 반도체사들이 그런 고민 크게 안하고 쓸 수 있도록 잘 포장해서 만들어놓기도 하거니와 어려운 부분은 기술 지원도 해주거든요. 그마저도 직접적인 관계를 갖고 일하는건 모통 제어기 개발 협력사 쪽입니다. 자동차 회사에서 직접 반도체 성능이나 특성 갖고 고민하는 경우는 매우 신기술의 경우가 대부분이에요. 이미 기술안정 되어서 많이 쓰이는 분야는 다들 평준화가 돼있어서 전체 시스템을 다루는 자동차 회사 입장에서는 크게 신경쓸 부분이 아니거든요. 하지만 요즘 핫한 이더넷이라던가 이미지센서, 레이더 뭐 이런 부분은 반도체사마다 특성이나 성능이 조금씩 달라서 전체 시스템 성능을 만족할 수 있는 제품 선정에 자동차 회사가 관여를 꽤 합니다. 의도적으로 하나의 제품군으로 통일하는 경우도 있구요. 참고로 현대차는 반도체에 관심이 꽤 많긴 합니다. 실제로 ASIC 개발 하는 조직도 있어요 ㅎㅎ (설계는 아니고 요구사양 내고 검증 하는 정도만 하긴 하지만요)

4. 아마도 자동차 회사만이 아니라 모듈 업체까지 포함해서 봐도 카메라나 레이더 같은 말단 센서 구동을 위한 코드를 직접 개발하는 곳은 없을거구요, 대부분은 실제 저 센서 공급 업체의 레퍼런스 및 기술지원으로 드라이버단을 구성하겠죠. 전체 시스템을 다루는 모듈/자동차 업체 입장에서는 개별 센서 정보 수집은 당연히 되는거고 오히려 “센서 퓨전” 이라고 부르는 부분이 제일 중요할거라고 생각합니다. 영상 데이터만이 아니라 각종 레이더, 초음파센서, 라이다 등을 통해 수집된 “다수의 센서 정보” 들을 하나의 통합 정보로서 일관되게 처리하는 기술인데요. 예를들어 옆차선 후방에서 내 차를 앞지르는 차가 있다고 한다면 센서 입장에서는 후방 센서에서 감지된 차량이 측방 센서를 거쳐 전방 센서에서 감지되게 됩니다. 이걸 서로 다른 센서들이 순차적으로 감지하게 되는데 이 정보를 모아서 서로 다른 오브젝트가 아닌 하나의 오브젝트로 인식해서 처리하는거죠.
서두에 일반적인 얘기를 말씀드렸지만, 자동차 회사는 굉장히 상위 레벨에서 전체적인 방향과 요구사항을 관리합니다. 영상처리 자체는 시스템 내에서 굉장히 low level이라 사실 “당연히 된다는 가정 하에” 시스템 판을 짜는 경우가 많을거에요. 물론 아랫쪽 돌아가는걸 알고 있냐 모르냐에 따라 업무 역량은 많이 차이나겠죠…

장황하게 답변을 쓰긴 했는데 정작 원하는 답변이 됐는지는 자신이 없네요.. 더 궁금한건 물어보시면 답변드릴 수 있는 한에서는 최대한 답변 드릴게요 :)

각 질문에 대한 답변에 앞서 일단 자동차 업계 돌아가는 구조를 간략하게 설명드릴 필요가 있을 것 같네요.
자동차라는게 워낙 거대하고 복잡한 시스템의 총합이고 여기에는 각 센서/액츄에이터 등 말단부터 이런 것들이 HW, SW적으로 통합된 시스템, 그리고 최종적으로는 이런 시스템들이 유기적으로 돌아가는 전체 차량 레벨까지 굉장히 다양한 깊이와 넓이의 일들이 복잡하게 얽혀있습니다. 따라서 특정 회사의 특정 조직, 특정 인원이 독립적으로 뭔가를 꾸려 나가기는 어렵고 굉장히 다양한 회사들이 다양한 역할을 상호 유기적으로 수행하게 됩니다. 자율주행이라는 카테고리만 해도 어마무지하게 큰 범위이며 여기에는 말단의 각 센서, 레이더 등을 개발하는 부품사와 이들을 조합하고 제어하는 모듈 업체, 이런 모듈에 대한 요구사항을 도출하고 각 모듈 간 유기적인 동작을 구성하는 자동차 업체까지 얽혀서 함께 결과를 도출해야하고, 여기에 HW개발 SW개발을 분리하고 SW개발도 플랫폼단과 미들웨어단, 어플리케이션 단을 구분하면 개발 주체가 또 나뉩니다. 평가/검증까지 들어가면 더 복잡해지죠. 업무의 깊이와 범위도 딱 구분된건 아니고 어떤 시스템은 차량 제조사가 SW 개발까지 하는 경우도 있고 또 어떤 시스템은 차량 제조사는 대략적인 요구사항만 내고 나머지는 다 개발 업체가 알아서 하는 경우도 있습니다. 뭐라고 딱 하나의 케이스로 정형화 하기가 어렵죠.
“일반적”으로는 자동차 회사에서는 전체적인 시스템 구성을 위한 요구사항을 도출하고, 일부 중요 핵심 로직을 개발하는 정도의 역할을 주로 수행합니다. 이게 문제 났을 때 책임소재도 있고 해서 웬만하면 직접 핸드코딩하고 설계하고 하는 경우는 피하려고 해요. 저도 사실 ADAS 쪽은 한다리 건너 아는 정도라 정확하게 어떻게 돌아가는지는 모르기 때문에 “일반적인” 범주에서 설명 드릴게요. 실제와는 좀 다를 수 있습니다.

1. 일단 사용하신 용어가 좀 모호하긴 합니다. 사람마다 조직마다 분야마다 같은 말을 미묘하게 다른 의미/깊이로 사용하고 있어서.. 제어 로직 개발은 말 그대로 어떤 기능이 어떻게 동작해야 하는가를 개발하는겁니다. 좀 더 어플리케이션 레벨에 가까워요. 주로 simulink로 개발하는 경우가 많은걸로 알고 있고(정확하진 않습니다) 이걸 코드 레벨로 구현하는건 또 다른 얘기입니다. 예를 들어 자율주행 중에 LFA(Lane Following Assist)라는 차선 유지 조향 보조 기능이 있는데, 이 기능의 제어 로직이라면 어떤 센서의 어떤 정보가 어떻게 조합되었을 때 이를 제어기하 위해서 steering을 어떻게 움직여야 하는가를 정의하는거죠. 실제 구현 레벨 앞단의 logical한 구성을 의미합니다.
제어기 모듈 개발이라고 하면 일단 느낌으로는 좀 더 실제 구현에 가까운 느낌이네요. 제어기라는건 일종의 아주 작은 (경우에 따라서는 꽤 큰) 임베디드 시스템이고, 여기에는 앞서 얘기한 다양한 제어 로직들이 “개별 기능” 으로써 포함됩니다. 어플리케이션에 가깝죠. 하지만 실제 제어기 구현을 위해서는 이런 기능들이 유기적으로 동작하기 위한 datapath 구성부터 해서 미들웨어 단의 각종 HW 드라이버들, 전원 체계 관리 및 메모리 관리, 소모전류 관리, 동작 모드 관리 및 각 모드에서 기능 동작 수준 정의, 타 제어기와의 통신 관리, 진단 및 업데이트 대응, 보안 대응 등등등 비 기능적인 요소들이 엄청 많죠.
아키텍처/플랫폼이란 말도 굉장히 다양하게 사용됩니다만, 이를 제어기 내부로 한정해서 생각해보면 아키텍처는 내부 소프트웨어 구조에서 각 기능 모듈 별 역할을 어디까지로 한정하고, 어떤 역할을 미들웨어로 정의하고 어플리케이션으로 정의할지, 모듈 간 데이터 전달은 어떻게 할지 등을 정의하는 내용이겠네요. 플랫폼은 말 그대로 AUTOSAR 같은 플랫폼을 의미하는 경우가 많고 이건 그냥 만들어져 있는 플랫폼을 적당히 가져다 쓰는 걸로 해결합니다. 제어기 개발하는 사람이 디테일한 신경을 쓰진 않아요.

2. ISO26262는 정의하고 있는 범위가 어마무지합니다. 고장 위험 분석부터 이를 대비하기 위한 HW SW 구성 및 생산 과정까지 요구하는 내용이 있고 각 과정 별 문서화까지 철저하게 요구합니다. 그래서 연구소 내에 기능안전 대응 전담 조직도 있어요. ASIL 분할이랑 memory partition은 레벨이 좀 다른 얘긴데, ASIL 분할은 높은 등급의 1가지 요소를 낮은 등급 2가지로 분할해서 “빡센 대책 하나 보다 좀 쉬운 대책 여러가지로 땜빵하자” 라는 일종의 방법론이구요, memory partition 같은건 이미 정해진 등급을 만족하기 위한 실제적인 실천 방법 중에 하나 정도로 생각할 수 있겠네요. AUTOSAR 표준이 일정 부분 26262 대응을 해주는 부분이 있는건 사실인데 이를 위한 AUTOSAR 개발 자체는 아마 오트론에서 할거구요, 이걸 포함한 전체 시스템의 26262 기준 만족을 위한 각종 개발 활동은 연관된 모든 개발사에서 공동으로 하는 부분입니다.

3. 당연히 모든 개발 경험은 도움이 됩니다. 특히 반도체는 차량 전장의 핵심 근간이 되므로.. 뭘 어떻게 해도 엮일 수 밖에 없죠. 근데 그 설계 경험이 직접적인 연관성이 있느냐.. 라고 하면 좀 다른 얘기긴 합니다. 이미 반도체사들이 그런 고민 크게 안하고 쓸 수 있도록 잘 포장해서 만들어놓기도 하거니와 어려운 부분은 기술 지원도 해주거든요. 그마저도 직접적인 관계를 갖고 일하는건 모통 제어기 개발 협력사 쪽입니다. 자동차 회사에서 직접 반도체 성능이나 특성 갖고 고민하는 경우는 매우 신기술의 경우가 대부분이에요. 이미 기술안정 되어서 많이 쓰이는 분야는 다들 평준화가 돼있어서 전체 시스템을 다루는 자동차 회사 입장에서는 크게 신경쓸 부분이 아니거든요. 하지만 요즘 핫한 이더넷이라던가 이미지센서, 레이더 뭐 이런 부분은 반도체사마다 특성이나 성능이 조금씩 달라서 전체 시스템 성능을 만족할 수 있는 제품 선정에 자동차 회사가 관여를 꽤 합니다. 의도적으로 하나의 제품군으로 통일하는 경우도 있구요. 참고로 현대차는 반도체에 관심이 꽤 많긴 합니다. 실제로 ASIC 개발 하는 조직도 있어요 ㅎㅎ (설계는 아니고 요구사양 내고 검증 하는 정도만 하긴 하지만요)

4. 아마도 자동차 회사만이 아니라 모듈 업체까지 포함해서 봐도 카메라나 레이더 같은 말단 센서 구동을 위한 코드를 직접 개발하는 곳은 없을거구요, 대부분은 실제 저 센서 공급 업체의 레퍼런스 및 기술지원으로 드라이버단을 구성하겠죠. 전체 시스템을 다루는 모듈/자동차 업체 입장에서는 개별 센서 정보 수집은 당연히 되는거고 오히려 “센서 퓨전” 이라고 부르는 부분이 제일 중요할거라고 생각합니다. 영상 데이터만이 아니라 각종 레이더, 초음파센서, 라이다 등을 통해 수집된 “다수의 센서 정보” 들을 하나의 통합 정보로서 일관되게 처리하는 기술인데요. 예를들어 옆차선 후방에서 내 차를 앞지르는 차가 있다고 한다면 센서 입장에서는 후방 센서에서 감지된 차량이 측방 센서를 거쳐 전방 센서에서 감지되게 됩니다. 이걸 서로 다른 센서들이 순차적으로 감지하게 되는데 이 정보를 모아서 서로 다른 오브젝트가 아닌 하나의 오브젝트로 인식해서 처리하는거죠.
서두에 일반적인 얘기를 말씀드렸지만, 자동차 회사는 굉장히 상위 레벨에서 전체적인 방향과 요구사항을 관리합니다. 영상처리 자체는 시스템 내에서 굉장히 low level이라 사실 “당연히 된다는 가정 하에” 시스템 판을 짜는 경우가 많을거에요. 물론 아랫쪽 돌아가는걸 알고 있냐 모르냐에 따라 업무 역량은 많이 차이나겠죠…

장황하게 답변을 쓰긴 했는데 정작 원하는 답변이 됐는지는 자신이 없네요.. 더 궁금한건 물어보시면 답변드릴 수 있는 한에서는 최대한 답변 드릴게요 :)