이 문서의 번역:

b. 부가가치 서비스

이미 논의한 자동차 핵심 기능 외에도, 추가적인 부가 서비스는 커넥티드 카의 진화를 만들어 내는데 중요한 역할을 하고 있다. 다음 부분에서 우리는 이러한 서비스에 대해 설명하고 이 일반적인 플랫폼이 취할 수 있는 다양한 형태에 대해 살펴볼 것이다.

eCall

eCall은 사고 현장에 긴급 서비스를 지시하는 데 필요한 시간을 단축하기 위해 커넥티드 카의 활용을 목적으로 하는 유럽 연합 계획이다. 일부 추정에 따르면, eCall 서비스는 도시 지역에서는 40%, 농촌 지역에서는 50%까지 긴급 반응 시간을 줄일 수 있으며 [EC1], 그 결과 매년 잠재적으로 2,500명의 생명을 구할 수 있다 [EC2].

다양한 센서 입력을 사용하여, 에어백과 벨트 텐셔너 등의 장치뿐만 아니라 내장형 가속도 센서에서 eCall은 충돌이 일어나기 전 잠재적인 충돌을 감지 할 수 있다. 이는 데이터 및 음성 서비스의 결합을 이용하여 백엔드와 상호 작용한다. 충돌이 발생하면 GPS 위치 및 차량 ID (VID)가 데이터 서비스를 통해 백엔드로 전송된다. 음성 서비스는 승객과의 상호 작용을 시작하도록 자동으로 활성화된다.

Bosch의 Mobility Services for Automotive의 책임자인 Tim Kornherr는 “우리 고객을 위해, 특히 사고 같은 스트레스성 상황에서는 고객이 모국어로 상담원에게 이야기 할 수 있는 것이 중요하다. 이는 고객이 여행하는 나라와 관계없이 이루어져야 한다. 우리의 eCall 솔루션은 운전자의 언어 선호도에 접근할 수 있으며, 따라서 들어오는 고통의 전화들을 그에 맞는 언어 능력을 가진 콜센터 직원에게 보낼 수 있다.”라고 설명한다.

음성 서비스를 통한 승객들로부터의 피드백 또는 사건에서 승객이 의식하지 못하는 부족함에 기반하여 결정되는 상황의 평가에 따라, 시스템은 관련이 응급 서비스를 알아낼 것이다. 유럽 연합에서 이는 PSAP (Public-Safety Answering Point)를 통해 관리된다. PSAP는 지역 응급 전화를 처리하고 통지 및 응급 서비스를 지시 할 수 있는 지방 자치 콜센터이다.

아래 도표는 eCall 시스템에 대한 자산 통합 아키텍처를 보여준다. 통신의 첫 번째 줄 (데이터 및 음성 수신기)은 일반적으로 통신 사업자 인터페이스에 따라 달라지며 OEM 또는 eCall 플랫폼 운영자 중 하나에 의해 제공될 수 있다.

                          AIA for eCall Service
                               

유럽 연합 내에서 필수 서비스로의 eCall 도입은 여러 번 연기되어 왔다. 이 지연 이유에 대해 언급한 Peiker의 상품 전략 책임자인 Christoph Schillo 박사는 “우리가 보는 바로는, 지연의 주된 이유가 eCall 서비스의 복잡성을 과소 평가했기 때문이다. eCall 서비스는 차 내의 하드웨어, 통신 사업자 서비스, 콜 센터 서비스, PSAP를 포함하는 상당수의 시스템과 인터페이스에 대한 기술 표준화 및 입법 규칙을 필요로 한다. 그리고 이 모두가 유럽 연합 내 여러 국가에 걸쳐 적용된다. 국가 이익도 중요한 역할을 한다. 예를 들어, 프랑스와 영국은 이미 자체 eCall 시스템을 가지고 있었다. 그런데, 프랑스의 시스템은 SMS 문자 메시지를 기반으로 하고 있어, 당신이 새해 전야에 사고가 날 경우 제대로 작동하지 않을 수 있다. 또한 일부 사업자들은 그들 자신을 위한 비지니스 모델을 보지 못했다. 그래서 BMW와 Mercedes 등 많은 OEM 업체가 나서서 그냥 자체 시스템을 구축했다고 한다. Mercedes 는 2012년에 9개국에서, 2013년에 10개국을 추가하며 출시를 시작했다. 이러한 OEM 업체들이 그들 스스로 전체 프로젝트를 관리하거나 필요한 하부시스템에 적합한 파트너를 찾을 수 있었기 때문에 가능한 일이었다.”고 설명한다.

유럽 연합은eCall 시스템이 이후 2018년부터 유럽 연합에서 판매되는 모든 새 자동차에 의무적으로 설치되어야 한다는 것에 결국 동의했다 [EC2].

bCall

eCall 서비스의 흥미로운 변형은 bCall 고장 서비스이다. 차량 고장이 발생하는 경우, 운전자는 일반적으로 수동으로 이 서비스를 활성화하고 콜센터 연결 버튼을 누를 필요가 있다. bCall 서비스의 향상 버전은 차량 ID 및 위치 등의 기본 데이터를 송신할 뿐만 아니라 콜센터 직원이 실시간 차량 진단 데이터에 접근 할 수 있도록 허용한다. 이는 ODB II 또는 유사한 인터페이스를 통해 필요한 데이터에 접근하는 bCall 서비스의 차 내 구성요소를 사용하여 이루어진다 [OB1]. 이 정보로 무장한 콜센터의 첫 단계 지원 팀은 상황에 대한 더 나은 초기 평가를 내릴 수 있으며 다음 단계를 결정할 수 있다. 예를 들면, 그들은 고장난 부분에 알맞은 여분 부품과 함께 서비스 차량을 보내기로 결정할 수 있다.

도난 차량 회수

커넥티드 카 서비스 분야에서의 또 다른 흥미로운 발전은 LoJack, Tracker, OnStar가 제공하는 도난 차량 회수 시스템에 관한 것이다.

이러한 시스템은 보통 차 내에 숨겨진 작은 무선 송수신기를 이용한다. 이 송수신기의 위치는 잠재적 납치범에 의해 쉽게 발견되는 것을 방지하기 위해, 대개 모든 자동차마다 다르다. 일단 설치되면, 추적 ID 및 자동차 등록 번호 (VIN)는 차량 제조사와 모델, 번호판, 색상 등의 추가 정보와 함께 추적 시스템에 등록된다. 차량 추적 시스템은 또한 미국의 NCIC (National Crime Information Center) 시스템과 같은 법 집행 기관의 IT 시스템과 통합 할 수 있다. 도난 사건의 경우, 차량 소유자는 사건을 보고하고 추적 시스템은 추적 장치를 활성화시켜, 도난 차량의 위치를 찾는 데 도움이 되는 신호를 발송한다.

사용 기반 보험

우리가 볼 커넥티드 카에 대한 마지막 부가가치 서비스는 “운전량에 따른 부과” 또는 “운전 방법에 따른 부과” 제도로 알려진 사용 기반 보험 (UBI)이다. 기본적인 아이디어는 보험 회사가 주행 성능 데이터에 대한 접근권을 얻는 대신 고객에게 차량 사용 (시간), 주행 거리, 방문 지역, 운전 행동에 기반한 보험 증서를 제공하는 것이다.

기존의 자동차 보험료는 인구 통계를 이용하여 계산되었기에 개별화되지 않았다. UBI는 이를 바꿀 것을 약속한다. 얼마나 멀리 그리고 얼마나 빨리 운전하는가, 얼마나 자주 세게 브레이크를 밟거나 방향을 트는가, 야간 및 주말 주행과 같은 운전 패턴 등 행동을 잡아내기 위해 차량에 설치된 장치를 사용하여 현재 운전 행동을 추적한다. 기존 인구 통계와 함께, 이 데이터는 각 운전자에 대해 고유의 위험 프로파일을 생성하는 데 사용되며, 각 피보험 운전자를 위한 고객 맞춤형 보험료를 계산하기 위한 기반을 형성한다. 일부 연구에 따르면 “좋은 운전자”에 대한 연간 UBI 보험료는 기존 정책 보다 최대 30 % 낮아질 수 있다 [LN1].

경쟁이 치열한 자동차 보험 부문의 경우, UBI는 다른 여러 가지 이유로 시장 변화 차별화 요인이 될 수 있는 잠재력을 가지고 있다:

• 낮은 보험료가 특히 더 좋은 운전자들의 잠재적 전환을 장려한다

• 운전자는 자신의 보험료를 낮게 유지하기 위해 안전하게 운전하도록 장려된다

• 보험 회사가 포함하는 위험의 정도는 감소한다

• 클레임이 적으며, 이는 보험 회사의 수익성을 증가시킨다

많은 보험 회사는 포트폴리오에 UBI 상품을 추가하기 시작했다. 예를 들어 미국에서는 Progressive, Allstate, State Farm, Travelers, Esurance, the Hartford, Safeco 및 GMAC 모두 이 길을 선택했다 [UBI1].

몇 가지 이유, 특히 개인 정보 보호 및 일반 이용성 문제 때문에 처음 소비자 측에서의 흡수는 느리게 일어났다. 그러나 이제 변화 할 것으로 보인다. 리서치 회사 Towers Watson에 따르면, 2014년 7월 현재 미국 운전자의 8.5 %가 UBI보험 증권을 소유하고 있으며, 이는 4.5%였던 2013년 2월보다 크게 증가한 수치이다.

UBI에의 대규모 지원을 위해서는 전문 UBI 관리 시스템이 필요하다. 이러한 해결책의 공급자 중 하나는 Tech Mahindra 이다. Tech Mahindra 솔루션은 세 가지 주요 구성 요소인 UBI 차량 추적 장치, 연결 및 장치 관리자 및 UBI 보험 어플리케이션으로 되어 있다. Tech Mahindra 솔루션의 자산 통합 아키텍처 (AIA)는 다음과 같다.

                           AIA for the UBI system
                           

UBI 차량 추적 장치는 고객의 차량에 설치된다. 이 장치는 표준 OBD II 어댑터 [OBD1]를 통해 자동차의 컨트롤에 연결된다. 이 인터페이스를 통해, 장치는 엔진 RPM, 차량 속도, 위치 정보 (위도, 경도 및 고도), 날짜, 시간, 배터리 전압과 엔진 파라미터 등의 데이터를 읽을 수 있다.

또한 이는 강력한 코너링 및 제동, 공격적인 가속 등 운전 사건에 관한 데이터를 읽을 수 있으며, UBI 관점에서 특히 흥미롭다. 장치 내의 GPRS / GSM 모뎀은 백엔드에 데이터를 전송한다. OBD 데이터는 서버로 전송되기 전, GPS 수신기를 통해 획득한 위치 데이터로 보강된다.

M2M 어플리케이션은 장치 관리 모듈과 UBI 비지니스 어플리케이션, 두 개의 주요 구성 요소로 구성된다. 장치 관리 모듈은 장치 활성화 및 연결을 관리한다. 장치 자체는 웹 어플리케이션 또는 SMS 인터페이스를 통해 원격으로 구성될 수 있다.

UBI 백엔드 어플리케이션은 차량 기본 데이터를 활용하고 Hadoop 클러스터는 들어오는 많은 양의 차량 데이터를 관리하는데 사용된다. 어플리케이션은 사용자 관리, 사건 관리, 고급 분석 및 운전자 점수 카드 기능 등의 비지니스 기능을 제공한다. 사건 관리 모듈은 차량으로부터 수신되는 알림을 관리하고, 또한 반응을 시작할 수 있다. 사용자와의 통신은 SMS 및 이메일 기반 알림을 통해 처리된다. 강력한 제동, 코너링, 가속, 과속의 이동 평균 및 위치별 평균 속도와 같은 고급 분석과 드라이버 점수 카드 동향 분석은 보험 회사에게 유용하다. 어플리케이션은 또한 공용 데이터 소스 (실시간으로 전후 사정과 관련된 정보를 제공), GIS 시스템 등의 백엔드 시스템, 보험 회사의 기존 기록 및 청구 관리 시스템과 통합된다.

데이터 집합은 UBI 관세 산출 및 계약 관리에서 중요한 역할을 한다. 아래 도표는 Tech Mahindra 에 의해 설계된 데이터 통합 모델의 개요를 제공한다. 이 모델은 보험 회사가 구조화된 방식으로 운전자 데이터를 집계하고 운전자 보험 요금을 산출하는 데 이 모델을 동적으로 사용할 수 있게 한다.

UBI data aggregation model (Source: Tech Mahindra)

많은 사람들에게 UBI의 기본 가치 제안은 적어도 처음에는 흥미롭게 들린다. M2M/IoT 사업의 초기 상징으로 UBI가 선택된 것은 별로 놀랄 일이 아니다. 많은 혁신과 마찬가지로, 흡수는 예상보다 더 느렸다. 그러나, 일부 연구를 기반으로 UBI는 마침내 실행 가능한 보험 모델로 관심을 끌고 있는 것 같다 [LN1].

그렇다면 왜 아직 개방형 자동차 앱 플랫폼을 사용하지 않는가?

eCall에서 UBI까지 이전에 논의된 자동차 부가가치 서비스의 예를 볼 때, 하나의 질문이 떠오른다. 왜 부가가치 서비스 개발이 그렇게 복잡한가? 각 솔루션 제공 업체들은 심지어 단 한 줄의 사업 논리 개발을 시작하기 전에, 차에 자체 하드웨어를 설치하고 백엔드에 자체 원거리 통신 링크를 설정하고, 백엔드에서 자신의 데이터 수집 및 사건 관리 시스템을 구현해야 하기 때문에 복잡하다.

개방형 (또는 적어도 반 개방형) 앱 생태계의 대규모 혁신 잠재력은 이미 애플, 삼성, 구글 등 스마트폰 업체들에 의해 검증되었다. 대부분의 주요 앱 스토어는 이제 수만 개의 어플리케이션을 포함하고 있으며, 이 어플리케이션의 대부분이 스마트폰 OS에서 제공하는 제어된 API를 통해 현대적인 스마트폰에 내장된 센서를 활용한다.

스마트폰 앱이 오작동하거나 시스템의 보안을 위해 스마트폰 OS에서 사용하는 샌드박스 메커니즘을 고장내는 경우, 최악의 상황은 핸드폰이 정지하거나 정해진 것보다 더 많은 데이터를 사용하는 것이다. 그러나 자동차 어플리케이션의 오작동은 훨씬 더 위험하여 생명을 위협할 수 있다.

우리가 이미 계기판에 대한 논의에서 살펴본 바와 같이, 자동차 인포테인먼트 시스템과 스마트폰 앱을 결합하기 위한 수많은 지속적인 노력이 있어왔다. 그러나 이러한 노력의 대부분은 인포테인먼트에만 중점을 두며, 위에서 설명한 것처럼 앱 링크 접근에 의해 제공되는 심층적인 통합의 달성은 고려하지 않는다. 그러나, 이러한 UBI와 eCall 같은 어플리케이션은 읽기 전용 단계일지라도, 핵심 자동차 기능과 심층적인 통합을 필요로 할 것이다. 아래에 설명된 Digital Horizon 시스템과 같은 더 발전된 시스템은 가장 효율적으로 작동하기 위해 자동차의 컨트롤에 실제 기록 접근을 필요로 할 것이다. OEM 업체의 경우, 외부 응용 프로그램에의 통제권을 넘기는 행위는 당연하게도 큰 위험을 동반하며, 그렇기에 대부분의 OEM 업체들은 여전히 자동차 생태계에 새로운 어플리케이션을 허용하기 전에 철두철미하고 긴 인증 절차를 필요로 한다.

그럼에도 불구하고 스마트폰 앱 생태계에서 보여지는 기하급수적 성장의 유형을 만들어내기 위해, OEM 업체들은 외부 애플리케이션이 핵심 자동차 기능에 접근할 수 있는 방법에 대해 더 많이 개방해야 한다.

아마도 이러한 개방형 자동차 앱 생태계를 만드는 첫 번째 단계는 차 안에 있는 것에는 덜 중점을 두고, 클라우드 등 차 밖에 있는 것에 대해 더 집중해야 한다.

많은 자동차관련 어플리케이션 서비스는 실제 차량 자체 내에서의 실행 환경을 필요로 하지 않는다. eCall 및 UBI 사례를 보자. 모두 필요한 데이터에 대한 접근을 제공하는 클라우드 기반 어플리케이션 플랫폼에 쉽게 구축 될 수 있다. 이러한 유형의 어플리케이션의 경우, 직접 자동차에 내장되는 것 또는 백엔드 자동차 데이터 관리 시스템을 다루는 것으로부터 얻어 질 수 있는 조금의 부가가치가 있다. 차량 데이터에 접근하기 위한 효율적인 가입 메커니즘과 함께 클라우드 기반의 개방형 자동차 어플리케이션 플랫폼은 완전히 충분해진다.

이 IoT의 한 귀퉁이가 향후 10년 내에 어떤 결과를 가져올지 지켜보는 것은 흥미로울 것이다. 앞으로 흥미 진진한 시간이 기다리고 있다.

              The OEM dilemma of dashboard supremacy (Source: mm1 Consulting)
              

앱 링크 방식의 주요 이점은 새로운 어플리케이션을 가능하게 하고 또한 자동차 특화 어플리케이션에 요구되는 많은 기본 자동차 기능을 활용할 수 있다는 점이다. 사용 기반 보험 예로 돌아가서, UBI 앱은 주행 거리, 평균 속도, 급격한 제동에 대한 데이터를 획득 할 수 있도록 운전 프로파일에 접근할 필요가 있다. 이 정보에 접근할 수 있는 유일한 방법은 예를 들어 CAN 버스를 통해 자동차의 내부 인터페이스를 거치는 것이다 [CAN1]. OEM 업체가 OEM 업체의 직접 통제 밖의 앱 스토어로부터 다운로드 가능한 앱에 매우 중요한 기본 자동차 인터페이스를 개방할 가능성은 거의 없는 것으로 보인다. 애플이나 구글에 이러한 종류의 통제권을 넘기는 것은 OEM 업체의 줄어든 사업 통제권을 의미할 뿐만 아니라, 또한 기능 안전에 대한 의문을 제기한다. 이러한 유형의 데이터를 읽는 것은 한 가지이지만, 차량 (가속, 조종 장치, 제동)에 대한 능동적인 통제권을 허용하는 것은 매우 다른 것이다. 그러나 다음 Digital Horizon 부분에서 볼 수 있듯이, 이러한 자동 주행 기능과 함께 지도 및 경로 데이터 등 자동차 계기판 정보를 모으는 능력은 IoT가 주는 가장 큰 기회 중 하나일 것이다. 이는 앱 링크와 같은 방식이 관련 위험을 제한하면서 서로 다른 세계 사이에 다리를 만드는 중요한 역할을 할 수 있는 곳이다.

이 계기판의 우위를 점하는 경쟁은 예측 가능한 미래에 대한 흥미로운 공간으로 남을 것이다. mm1 Consulting의 Stella Löffler에 따르면, “아직 우세한 해결책은 없다. 중기적으로, 정답은 아마 자동차 세그먼트마다, OEM 업체마다 다양할 것이다.”

이 문서의 번역:
b.부가가치_서비스.txt · 마지막으로 수정됨: 2015/09/15 17:24 저자 wikiadmin
CC Attribution-Share Alike 3.0 Unported
Powered by PHP Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 Valid HTML5