공유되는 차량 내 런타임은 어떤 모델이 활성화된 상태로 유지되고, 어떤 모델은 작동 조건에 따라 필요할 때만 실행되도록 관리할 수 있습니다.
상용차의 엣지 컴퓨팅( AI ) 기능이 확대됨에 따라 자원 문제가 대두되고 있습니다. 모든 모델을 지속적으로 구동하면 한정된 연산 능력과 메모리에 대한 부담이 가중되어, 새로운 기능을 통합하고 검증하며 운영하는 것이 더욱 어려워집니다. 아키텍처 측면에서 해결해야 할 과제는 차량에 할당된 제한된 자원 내에서 더 많은 지능을 어떻게 지원할 것인가 하는 점입니다.
모델이 하나씩 추가될 때마다 CPU 또는 가속기 용량, 메모리, 통합 작업 및 검증 과정이 필요할 수 있습니다. 하지만 진단 상황이나 서비스 워크플로우 중에 필요한 모델이 모든 주행 구간 내내 실행될 이유는 거의 없습니다. 해당 모델의 기능이 필요하지 않을 때에도 계속 활성화된 상태로 유지하면 실행 자원을 불필요하게 소모하게 됩니다.
제조업체 입장에서는 이로 인해 초기 생산 단계를 훨씬 넘어서는 설계상의 과제가 발생합니다. 상용차는 수명이 길게 이어지는데, FleetOwner는 “‘차량 운용사들은 지난 10년 넘게 이토록 오래된 장비를 운용한 적이 없다.”라고 보도했습니다. 제조 시점에 탑재된 컴퓨팅 성능과 메모리 용량은 대체로 고정되어 있지만, 그 위에서 실행되는 소프트웨어와 AI 에 대한 기대치는 계속 높아지고 있습니다. 엔지니어링 팀은 새로운 워크로드가 기존 기능과 어떻게 조화를 이룰지, 그리고 차량 전체에 걸쳐 이를 어떻게 배포, 업데이트 및 모니터링할지 결정해야 합니다.
운영 담당자와 서비스 팀의 경우, 데이터에서도 동일한 제약 사항이 나타납니다. 스토리지, 대역폭, 연결성 등의 한계로 인해 클라우드로 전송할 수 있는 원격 측정 데이터의 양이 제한되며, 대량의 데이터를 수집하다 보면 팀은 진단에 중요한 이벤트와 신호를 찾아내느라 애를 먹게 됩니다. 이러한 상충 관계는 피하기 어렵습니다. 모든 데이터를 클라우드로 전송하고 비용과 잡음을 감수할 것인지, 아니면 전송량을 줄여 핵심 이벤트를 놓칠 위험을 감수할 것인지 선택해야 하기 때문입니다.
두 문제 모두 같은 해답을 제시합니다: 지능을 차량으로 이전하고, 이를 개별적이고 상시 가동되는 모델들의 집합이 아닌 공유 차량 인프라로 관리해야 합니다. 공통 런타임은 모델 포트폴리오를 관리하며, 각 기능의 요구 사항에 따라 실행 리소스를 할당할 수 있습니다.
배포와 실행 분리
핵심 개념은 “배포됨”과 “실행 중”을 분리하는 것입니다. 차량에 모델을 상주시키는 것과 해당 모델을 실행하는 것은 별개의 결정 사항입니다. 배포된 모델은 여전히 저장 공간을 차지하지만, 그 실행은 운영상의 필요에 따라 관리될 수 있습니다.
이러한 구분을 통해 두 가지 유형의 에지 인텔리전스가 공존할 수 있습니다. 지속형 인텔리전스에는 연속적인 기능이나 안전에 중요한 기능을 지원하기 위해 항상 활성화된 상태를 유지해야 하는 모델이 포함됩니다. 지속형 인텔리전스의 예로는, 주행 중 카메라 영상을 처리하여 차량, 보행자, 자전거 이용자를 식별함으로써 충돌을 방지하는 ADAS 도로 물체 감지 모델을 들 수 있습니다.
주문형 인텔리전스에는 차량 상황이나 운영 조건에 따라 필요할 때만 활성화되는 모델이 포함됩니다. 주문형 인텔리전스의 예로, 충전 중이거나 차고에 정차해 있을 때 활성화되어 배터리 성능 저하를 평가하고 유지보수가 필요함을 알리는 배터리 상태 평가 모델을 들 수 있습니다. 동일한 하드웨어에서 이 두 가지를 모두 지원하려면, 중단될 수 없는 기능을 방해하지 않으면서도 어떤 작업을 언제, 어떤 리소스를 사용하여 실행할지 결정해야 합니다.
공유 차량 내 런타임이 이러한 결정을 내릴 수 있습니다. 이 런타임은 배포, 활성화, 비활성화, 모델 버전, 차량 신호에 대한 접근, 출력 및 모니터링을 관리하는 동시에, 각 기능의 요구 사항에 따라 CPU, 메모리 및 기타 리소스를 할당할 수 있습니다.
이러한 결정은 유효성 검증 및 리소스 가용성을 포함하여 각 기능의 요구 사항을 준수해야 합니다. 온디맨드 실행은 통합이나 유효성 검증 작업을 없애는 것이 아니라, 동시에 실행될 필요가 없는 워크로드를 관리할 수 있는 방법을 제공합니다.
모델이 실행되는 시점은 차량 상황에 따라 결정되도록 한다
차량 신호, 진단 이벤트, 작동 모드, 지리적 위치, 서비스 상황 및 기타 모델 출력값은 모델 활성화에 필요한 입력값으로 활용될 수 있습니다. 차량 상태가 트리거를 생성하면 플랫폼이 모델을 활성화하고, 모델은 해당 작업을 수행하며, 작업이 완료되면 플랫폼이 모델을 비활성화합니다. 모델은 그 기능이 필요한 동안에만 리소스를 소비합니다.
활성화된 모델은 상시 실행되는 함수와 동일한 리소스를 놓고 경쟁하기 때문에, 이를 실제로 적용하려면 CPU 및 RAM 사용량, 스토리지, 모델 규모, 동시 실행 중인 모델에 대한 가시성이 필요합니다. 또한 엔지니어링 및 운영 팀은 전체 클러스터에 걸친 배포 현황, 즉 무엇이 설치되어 있는지, 무엇이 실행 중인지, 그리고 사용 가능한 리소스가 요청된 워크로드를 지원할 수 있는지 여부에 대한 가시성을 확보해야 합니다.
공유 오케스트레이션 계층을 사용하면 각 애플리케이션마다 별도의 아키텍처를 구축할 필요 없이 다양한 애플리케이션을 일관되게 관리할 수 있습니다. 여기에는 원격 진단, 엣지 로그 분석, 구성 모니터링, 서비스 모드 또는 샵 모드, 모델 평가, 대상별 엔지니어링 워크플로 등이 포함되며, 이들 각각은 서로 다른 실행 요구 사항을 가지고 있습니다.
로컬에서 감지하고 선택적으로 수집
차량 데이터 수집을 통해 이 아키텍처가 실제로 어떤 변화를 가져오는지 알 수 있습니다. 클라우드 분석을 중심으로 한 워크플로우에서 팀은 데이터를 수집하고, 업로드하며, 이상 징후를 탐색하고, 주목할 만한 이벤트를 식별하고, 관련 신호를 추출한 다음 문제를 진단합니다.
엣지 지능형 워크플로는 이러한 순서를 바꿉니다. 즉, 로컬에서 이상 현상을 감지하고, 대상에 맞춘 데이터 수집을 촉발하며, 관련 맥락 정보를 업로드한 뒤 진단을 내립니다. 이제 어떤 데이터가 중요한지에 대한 결정 권한이 차량 내부로 옮겨갈 수 있게 되었습니다.
Sonatus’s Fastlane™ Edge ‘스마트 트리거(Smart Triggers)’ 기능이 그 구체적인 예 중 하나입니다. 스마트 트리거는 차량 내 엣지 런타임에서 실행되는 ‘ AI ’ 모델을 Fastlane™ Collector연동됩니다. 엣지에 배치된 경량 이상 탐지 모델이나 수학적 함수는 엔진 동작 임계값을 모니터링할 수 있습니다. 비정상적인 상태를 감지하면, 해당 이벤트와 관련된 엔진 신호를 포착하는 Fastlane Collector 해당 이벤트와 관련된 엔진 신호를 캡처하는 정책을 실행합니다. 대상 데이터 수집은 엔진 이상 현상이 감지되었을 때에만 수행됩니다.
이러한 접근 방식은 더 관련성 높은 진단 데이터 세트를 생성하고, 차량과 클라우드 간의 불필요한 데이터 전송 및 수동 로그 검색을 줄일 수 있습니다. 연결 사용량, 저장 공간 사용량 또는 조사 시간이 개선되는지는 탐지 품질과 수집 정책에 따라 달라집니다.
궁극적으로, 이는 아키텍처적 관점에서 배포, 실행, 리소스 및 라이프사이클 관리를 종합적으로 고려해야 함을 의미합니다. 차량은 설치된 모든 모델이 지속적으로 실행될 필요 없이, 점차 확대되는 ‘ AI ’ 기능 포트폴리오를 지원할 수 있습니다. 에지 AI 는 지능이 차량의 관리 가능한 기능이 될 때 확장성을 발휘합니다.