KR20210116162A - 차량용 운영 체제와 차량 제조업체 사용자 관리 시스템의 통합 - Google Patents
차량용 운영 체제와 차량 제조업체 사용자 관리 시스템의 통합 Download PDFInfo
- Publication number
- KR20210116162A KR20210116162A KR1020200079252A KR20200079252A KR20210116162A KR 20210116162 A KR20210116162 A KR 20210116162A KR 1020200079252 A KR1020200079252 A KR 1020200079252A KR 20200079252 A KR20200079252 A KR 20200079252A KR 20210116162 A KR20210116162 A KR 20210116162A
- Authority
- KR
- South Korea
- Prior art keywords
- user
- message
- operating system
- vehicle
- interface
- Prior art date
Links
- 230000010354 integration Effects 0.000 title 1
- 238000000034 method Methods 0.000 claims abstract description 62
- 230000008859 change Effects 0.000 claims description 49
- 230000009471 action Effects 0.000 claims description 8
- 238000012508 change request Methods 0.000 claims description 8
- 238000007726 management method Methods 0.000 description 85
- 230000004044 response Effects 0.000 description 33
- 238000005516 engineering process Methods 0.000 description 15
- 239000011800 void material Substances 0.000 description 15
- 230000003068 static effect Effects 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 9
- 238000006243 chemical reaction Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 101000767160 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) Intracellular protein transport protein USO1 Proteins 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 101100446506 Mus musculus Fgf3 gene Proteins 0.000 description 3
- 230000001815 facial effect Effects 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 101100348848 Mus musculus Notch4 gene Proteins 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000004378 air conditioning Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 238000010438 heat treatment Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000014616 translation Effects 0.000 description 2
- 240000000467 Carum carvi Species 0.000 description 1
- 235000005747 Carum carvi Nutrition 0.000 description 1
- PEDCQBHIVMGVHV-UHFFFAOYSA-N Glycerine Chemical compound OCC(O)CO PEDCQBHIVMGVHV-UHFFFAOYSA-N 0.000 description 1
- 101100317378 Mus musculus Wnt3 gene Proteins 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 239000011230 binding agent Substances 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000001172 regenerating effect Effects 0.000 description 1
- 239000004984 smart glass Substances 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000009423 ventilation Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
- G06F9/4451—User profiles; Roaming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
- B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
Abstract
차량용 사용자 관리 서비스와 관련된 디바이스 및 방법이 개시된다. 디바이스의 하나 이상의 프로세서는 제1 운영 체제를 실행하여 차량에 사용자 관리 서비스를 제공할 수 있다. 제1 운영 체제는 제2 운영 체제가 사용자 관리 동작을 호출할 수 있는 제2 운영 체제에 인터페이스를 제공할 수 있다. 제1 운영 체제는 사용자 관리와 관련된 제1 메시지를 생성할 수 있다. 인터페이스는 제1 메시지를 제2 운영 체제에 제공할 수 있다. 인터페이스는 제2 운영 체제로부터 제2 메시지를 수신할 수 있다. 제2 메시지는 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련될 수 있다.
Description
본 출원은 2020년 3월 17일에 출원한 미국 가출원 제62/990,910호에 관련된 것으로 그의 우선권을 주장하며, 그 전체 내용은 본원에 참조로 포함된다.
차량은 HVAC(난방, 환기 및 공조) 시스템, 조명 시스템(내부 및/또는 외부 조명 제어용), 인포테인먼트 시스템, 좌석 시스템(운전자 및/또는 승객 좌석의 위치 제어용) 등과 같은 차량 시스템을 제어하기 위한 인터페이스(GUI와 같은)를 나타내는 소위 "헤드 유닛" 또는 다른 통합 컴퓨팅 디바이스를 포함할 수 있다. 헤드 유닛은 차량 시스템에 하나 이상의 커맨드(본 명세서에서 "커맨드 세트"라고도 함)를 발행하여 하나 이상의 차량 시스템의 동작 상태를 변경할 수 있다.
자동차, 모터 사이클, 버스, 레저용 차량(RV), 세미-트레일러 트럭, 트랙터 또는 다른 유형의 농기계, 기차, 비행기, 드론, 헬리콥터, 개인 운송 차량 등과 같은 차량의 다른 사용자는 이들 차량 시스템용 설정에 대해 다른 선호도를 가질 수 있다. 예를 들어, 키가 큰 운전자는 동일한 차량의 더 작은 운전자보다 좌석 위치가 핸들에서 더 멀어지며 다른 미러 설정을 선호할 수 있다. 다른 운전자는 다른 스테이션 설정, 온도 제어 설정, 안전 설정, 주행 설정 등을 선호할 수도 있다. 이와 같이, 차량 제조업체(오리지널 장비 제조업체 또는 OEM이라고도 함)는 차량에 사용자 관리 기능을 내장하고 있다. 예를 들어, 많은 차량에서 사용자가 해당 사용자와 관련된 맞춤형 설정을 저장할 수 있다. 버튼과 같은 인터페이스와 상호 작용함으로써 사용자는 다양한 시스템의 설정을 기존 설정에서 사용자 자신이 선호하는 맞춤형 설정으로 빠르게 이동할 수 있다.
동일한 제조업체의 다른 모델뿐만 아니라 다른 제조업체의 모델 사이에 (기능 및 작동 측면에서) 다양한 차량 시스템(26)을 고려하면, 헤드 유닛(24)은 커맨드 세트의 수동 구성에 시간이 많이 걸리고 비용이 많이 들고 오류가 발생하기 쉽기 때문에 일반적으로 차량 시스템의 최고 비율을 제어하는 커맨드 세트를 출력하도록 구성될 수 있다.
게다가, 제조업체는 각각의 동작 상태 변경을 수행하기 위해 커맨드 세트를 정적으로 코딩(다시 말해, "하드 코딩")할 수 있다. 즉, 제조업체는 차량 헤드 유닛이 하나 이상의 시스템과 통신할 수 있는 특정 제어 버스 프로토콜(그의 일부는 독점적일 수 있음)을 따르도록 커맨드 세트를 정적으로 코딩할 수 있다. 제조업체는 차량 헤드 유닛에 의해 실행되는 운영 체제를 하드 코딩하여 제어 버스 프로토콜을 따르는 커맨드 세트를 생성할 수 있다. 각각의 커맨드 세트는 하나 이상의 시스템의 제어 버스 및/또는 벤더 등에 의해 변할 수 있어, 결과적으로 차량의 특정 구성에 대한 커맨드 세트의 정적 코딩에 시간이 걸리는데, 이는 심지어 차량 모델 트림(trim) 레벨사이에서도 변할 수 있다.
일반적으로, 본 개시의 기술은 차량 컴퓨팅 디바이스(예를 들어, 차량 헤드 유닛)가 차량에 사용자 관리 서비스를 제공할 수 있게 하는 것에 관한 것이다. 차량 헤드 유닛의 제1 운영 체제는 인체 공학적 시스템(예를 들어, 좌석, 핸들 및/또는 페달 시스템), 인포테인먼트 시스템, 온도 시스템, 안전 시스템 및 주행 모드 시스템과 같은 차량상의 다양한 시스템의 설정을 제어할 수 있는 차량상의 제2 운영 체제(차량 헤드 유닛일 수도 있음)와 상호 작용할 수 있다. 차량 헤드 유닛은 균일한 메시지 세트를 지원하는 제1 운영 체제를 실행할 수 있는 반면, 제2 운영 체제는 복수의 제어 버스 프로토콜의 특정 제어 버스 프로토콜에 따라 지정된 로컬 제어 메시지를 전달(communicate)하여 차량의 다양한 시스템을 제어할 수 있다. 차량 헤드 유닛의 제1 운영 체제에 의해 제공되는 사용자 관리 서비스를 지원하기 위해 특정 로컬 제어 메시지를 지원하도록 제1 운영 체제를 하드 코딩하는 대신, 본 개시의 기술의 다양한 양태는 제1 운영 체제가 사용자 관리 서비스를 제공하기 위한 인터페이스, 예를 들어, 애플리케이션 프로그래밍 인터페이스("API")를 제2 운영 체제에 제공할 수 있게 한다. 제2 운영 체제는 API와 인터페이스하기 위한 하드웨어 추상화 계층("HAL")을 포함할 수 있다.
이와 같이, 기술의 다양한 양태는 제조업체가 API로부터의 메시지를 제2 운영 체제에 의해 작동하여 차량의 하나 이상의 시스템을 제어할 수 있는 메시지로의 변환(translation)을 제공할 수 있는 HAL을 정의할 수 있게 할 수 있다. 이러한 방식으로, 헤드 유닛의 제1 운영 체제는 차량에 사용자 관리 서비스를 제공할 수 있다. API와 HAL만 정의될 수 있으므로, 로컬 커맨드 세트만 지원하기 위해 제1 운영 체제 또는 제2 운영 체제내에서 정적으로 하드 코딩 변환 맵핑보다 오히려, 본 기술의 다양한 양태는 차량 헤드 유닛 운영 체제가 개발될 수 있는 속도를 향상시킬 수 있고, 새로운 또는 변경되는 제어 버스 프로토콜과의 상호 운용성을 향상시키고, 사용자 관리 서비스를 제공하는 이러한 운영 체제의 신속한 배포를 수용하면서 차량 헤드 유닛 운영 체제의 개발을 개선할 수 있다.
일 예에서, 기술의 다양한 양태는 차량의 하나 이상의 프로세서에 의해, 차량에 사용자 관리 서비스를 제공하도록 제1 운영 체제를 실행하는 단계와; 하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 제2 운영 체제가 사용자 관리 동작을 호출하는 인터페이스를 제2 운영 체제에 제시하는 단계와; 하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 사용자 관리와 관련된 제1 메시지를 생성하는 단계와; 인터페이스에 의해, 제1 메시지를 제2 운영 체제로 제공하는 단계와; 그리고 인터페이스에 의해, 제2 운영 체제로부터 상기 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련된 제2 메시지를 수신하는 단계를 포함한다.
다른 예에서, 기술의 다양한 양태는 차량과 상호 작용하도록 구성된 디바이스에 관한 것으로, 이 디바이스는 사용자 관리 데이터를 저장하도록 구성된 메모리; 및 메모리에 통신 가능하게 결합되고 사용자 관리 동작을 호출하기 위해 제2 운영 체제에 인터페이스를 제시하는 제1 운영 체제를 실행하도록 구성된 하나 이상의 프로세서를 포함하고, 상기 제1 운영 체제는 사용자 관리와 관련된 제1 메시지를 생성하도록 구성되고, 상기 인터페이스는 제1 메시지를 제2 운영 체제에 제공하도록 구성되고, 상기 인터페이스는 제2 운영 체제로부터 제2 메시지를 수신하도록 더 구성되며, 상기 제2 메시지 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련되고, 상기 제1 운영 체제는 제1 메시지에 기초하여 차량에 사용자 관리 서비스를 제공한다.
다른 예에서, 기술의 다양한 양태는 명령들이 저장된 비-일시적 컴퓨터 판독 가능 저장 매체에 관한 것으로, 상기 명령들은 실행될 때, 차량 헤드 유닛의 하나 이상의 프로세서로 하여금: 차량에 사용자 관리 서비스를 제공하기 위해 제1 운영 체제를 실행하고; 제2 운영 체제가 사용자 관리 동작을 호출하는 제1 운영 체제의 인터페이스를 제2 운영 체제에 제시하고; 사용자 관리와 관련된 제1 메시지를 생성하고; 인터페이스에 의해, 제1 메시지를 제2 운영 체제에 제공하고; 그리고 인터페이스에 의해, 제2 운영 체제로부터 상기 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련된 제2 메시지를 수신하게 한다.
하나 이상의 예의 세부 사항은 첨부 도면 및 이하의 설명에서 설명된다. 본 개시의 다른 특징, 목적 및 이점은 상세한 설명 및 도면 및 청구 범위로부터 명백할 것이다.
도 1은 본 개시에서 설명된 기술의 다양한 양태를 수행하도록 구성된 예시적인 차량을 도시하는 블록도이다.
도 2는 도 1의 헤드 유닛의 예를 보다 상세하게 나타내는 블록도이다.
도 3은 본 개시의 기술에 따른 성공적인 사용자 전환의 예를 도시한 흐름도이다.
도 4는 본 개시의 기술에 따른 실패한 사용자 전환의 예를 도시한 흐름도이다.
도 5는 본 개시의 기술에 따른 실패한 사용자 전환의 다른 예를 도시한 흐름도이다.
도 6은 본 개시의 기술에 따른 성공적인 사용자 생성의 예를 도시하는 흐름도이다.
도 7은 본 개시의 기술에 따른 실패한 사용자 생성의 예를 도시한 흐름도이다.
도 8은 본 개시의 기술에 따른 실패한 사용자 생성의 다른 예를 도시한 흐름도이다.
도 9는 본 개시의 기술에 따른 성공적인 사용자 제거의 예를 도시하는 흐름도이다.
도 10은 본 개시의 기술에 따른 실패한 사용자 제거의 예를 도시하는 흐름도이다.
도 11은 본 개시의 기술에 따른 실패한 사용자 제거의 다른 예를 도시한 흐름도이다.
도 12는 본 개시의 기술에 따른 사용자와 인증 팩터의 연관의 예를 도시한 흐름도이다.
도 13은 본 개시의 기술에 따른 사용자 관리 서비스를 제공하는 예의 흐름도이다.
도 14a 내지 도 14c는 본 개시의 기술에 따른 사용자 관리 서비스를 제공하는 추가 예의 흐름도이다.
도 15는 제1 운영 체제 및 제2 운영 체제의 구성 요소의 예를 나타내는 블록도이다.
도 2는 도 1의 헤드 유닛의 예를 보다 상세하게 나타내는 블록도이다.
도 3은 본 개시의 기술에 따른 성공적인 사용자 전환의 예를 도시한 흐름도이다.
도 4는 본 개시의 기술에 따른 실패한 사용자 전환의 예를 도시한 흐름도이다.
도 5는 본 개시의 기술에 따른 실패한 사용자 전환의 다른 예를 도시한 흐름도이다.
도 6은 본 개시의 기술에 따른 성공적인 사용자 생성의 예를 도시하는 흐름도이다.
도 7은 본 개시의 기술에 따른 실패한 사용자 생성의 예를 도시한 흐름도이다.
도 8은 본 개시의 기술에 따른 실패한 사용자 생성의 다른 예를 도시한 흐름도이다.
도 9는 본 개시의 기술에 따른 성공적인 사용자 제거의 예를 도시하는 흐름도이다.
도 10은 본 개시의 기술에 따른 실패한 사용자 제거의 예를 도시하는 흐름도이다.
도 11은 본 개시의 기술에 따른 실패한 사용자 제거의 다른 예를 도시한 흐름도이다.
도 12는 본 개시의 기술에 따른 사용자와 인증 팩터의 연관의 예를 도시한 흐름도이다.
도 13은 본 개시의 기술에 따른 사용자 관리 서비스를 제공하는 예의 흐름도이다.
도 14a 내지 도 14c는 본 개시의 기술에 따른 사용자 관리 서비스를 제공하는 추가 예의 흐름도이다.
도 15는 제1 운영 체제 및 제2 운영 체제의 구성 요소의 예를 나타내는 블록도이다.
도 1은 본 개시에서 설명된 기술의 다양한 양태를 수행하도록 구성된 예시적인 차량(8)을 도시하는 블록도이다. 도 1의 예에서, 차량(8)은 이하의 설명에서 자동차인 것으로 가정된다. 그러나, 본 개시에 기술된 기술은 모터 사이클, 버스, 레저용 차량(RV), 세미-트레일러 트럭, 트랙터 또는 다유형의 농기계, 기차, 비행기, 드론, 헬리콥터, 개인 운송 차량 등과 같이, 위치들 사이에서 하나 이상의 탑승자를 운반할 수 있는 임의의 유형의 차량에 적용될 수 있다. 일부 예에서, 차량(8)은 자율 차량일 수 있다.
도 1의 예에서, 차량(8)은 프로세서(15), 그래픽 처리 디바이스(GPU)(14) 및 시스템 메모리(16)를 포함한다. 일부 예에서, 프로세서(15), GPU(14) 및 송수신기 모듈(도 1에 미도시됨)은 집적 회로(IC)로서 형성될 수 있다. 예를 들어, IC는 칩 패키지 내의 프로세싱 칩으로 간주될 수 있고, 시스템 온 칩(SoC)일 수 있다.
프로세서(15)와 GPU(14)의 예는 하나 이상의 디지털 신호 프로세서(DSP), 범용 마이크로 프로세서, 주문형 집적 회로(ASIC), 필드 프로그래머블 로직 어레이(FPGA) 또는 다른 등가 집적 또는 이산 논리 회로를 포함하지만 이에 한정되지는 않는다. 프로세서(15)는 차량(8)의 중앙 처리 장치(CPU)를 나타낼 수 있다. 일부 예에서, GPU(14)는 그래픽 처리에 적합한 대규모 병렬 처리 능력을 GPU(14)에 제공하는 집적 및/또는 이산 논리 회로를 포함하는 특수화된 하드웨어일 수 있다. 일부 경우, GPU(14)는 또한 범용 처리 기능을 포함할 수 있고, 범용 처리 태스크(예를 들어, 비-그래픽 관련 태스크)를 구현할 때 범용 GPU(GPGPU)로 지칭될 수 있다. 전용 GPU(14)로 도시되어 있지만, GPU(14)는 기본 회로 보드(예를 들어 소위 "마더 보드")에 통합되거나 프로세서(15)에 통합된 통합 GPU를 나타낼 수 있다.
프로세서(15)는 다양한 유형의 애플리케이션을 실행할 수 있다. 애플리케이션의 예로는 웹 브라우저, 이메일 애플리케이션, 스프레드 시트, 비디오 게임, 또는 가시적인 객체를 생성하는 기타 애플리케이션이 있다. 시스템 메모리(16)는 하나 이상의 애플리케이션의 실행을 위한 명령들을 저장할 수 있다. 프로세서(15)에 의한 애플리케이션의 실행은 프로세서(15)가 디스플레이될 이미지 컨텐츠에 대한 그래픽스 데이터를 생성하게 한다. 프로세서(15)는 프로세서(15)가 GPU(14)로 전송하는 명령 또는 커맨드에 기초하여 추가 처리를 위한 이미지 컨텐츠의 그래픽 데이터를 GPU(14)로 전송할 수 있다.
시스템 메모리(16)는 또한 사용자 관리 데이터(35)를 저장할 수 있다. 사용자 관리 데이터(35)는 인증된 사용자에 대한 사용자 식별(id), 사용자 이름, 하나 이상의 차량 시스템(26)의 동작 상태에 대한 사용자 선호 설정 또는 사용자와 관련된 인증 형태와 같은 사용자와 관련된 다른 정보를 포함할 수 있다. 일부 예에서, 이러한 정보의 전부 또는 일부는 사용자 관리 데이터에 사용자 프로필로서 저장될 수 있다. 사용자 관리 데이터(35)는 시스템 메모리(16)에 기록되거나 HAL(28) 또는 제2 OS(31)에 의해 시스템 메모리(16)로부터 판독될 수 있고, 일부 예에서 차량 사용자 관리 시스템을 함께 형성할 수 있다.
프로세서(15)는 API(application programming interface)에 따라 GPU(14)와 통신할 수 있다. 게다가, 본 개시에서 설명된 기술들은 API에 따라 기능할 필요가 없으며, 프로세서(15)와 GPU(14)는 GPU(14)와 통신하기 위한 임의의 기술을 이용할 수 있다.
시스템 메모리(16)는 차량(8)을 위한 메모리를 나타낼 수 있다. 시스템 메모리(16)는 하나 이상의 컴퓨터 판독 가능 저장 매체를 포함할 수 있다. 시스템 메모리(16)의 예는 랜덤 액세스 메모리(RAM), 전기적으로 소거 가능한 프로그램 가능 판독 전용 메모리(EEPROM), 플래시 메모리, 또는 명령 및/또는 데이터 구조의 형태로 원하는 프로그램 코드를 운반 또는 저장하는데 사용될 수 있고 컴퓨터 또는 프로세서에 의해 액세스될 수 있는 다른 매체를 포함하지만 이에 제한되지는 않는다.
일부 양태에서, 시스템 메모리(16)는 프로세서(15)가 프로세서(15)에 본 개시에서 언급된 기능들을 수행하게 하는 명령들을 포함할 수 있다. 따라서, 시스템 메모리(16)는 실행될 때 하나 이상의 프로세서(예를 들어, 프로세서(15))로 하여금 다양한 기능들을 수행하게 하는 명령들이 저장된 비-일시적 컴퓨터 판독 가능 저장 매체일 수 있다.
시스템 메모리(16)는 비-일시적 저장 매체이다. "비-일시적"이라는 용어는 저장 매체가 반송파 또는 전파 신호로 구현되지 않음을 나타낸다. 그러나, "비-일시적"이라는 용어는 시스템 메모리(16)가 이동식이 아니거나 그의 컨텐츠가 정적인 것을 의미하는 것으로 해석되어서는 안된다. 일 예로서, 시스템 메모리(16)는 차량(8)으로부터 제거되어 다른 디바이스로 이동될 수 있다. 다른 예로서, 시스템 메모리(16)와 실질적으로 유사한 메모리가 차량(8)에 삽입될 수 있다. 특정 예에서, 비-일시적 저장 매체는 시간 경과에 따라 (예를 들어, RAM에서) 변경될 수 있는 데이터를 저장할 수 있다.
도 1의 예에 더 도시된 바와 같이, 차량(8)은 디스플레이(20) 및 사용자 인터페이스(22)를 포함할 수 있다. 디스플레이(20)는 이미지가 투사될 수 있는 임의의 유형의 수동 반사형 스크린를 나타내거나, 또는 이미지를 디스플레이할 수 있는 능동 반사형 또는 발광형 또는 투과형 디스플레이(예를 들어, 발광 다이오드(LED) 디스플레이, 유기 LED(OLED) 디스플레이, 액정 디스플레이(LCD) 또는 임의의 다른 유형의 활성 디스플레이와 같은)를 나타낼 수 있다. 단일 디스플레이(20)를 포함하는 것으로 도시되었지만, 차량(8)은 차량(8)의 캐빈 전체에 걸쳐 위치될 수 있는 다수의 디스플레이를 포함할 수 있다. 일부 예에서, 수동 버전의 디스플레이(20) 또는 특정 유형의 활성 버전의 디스플레이(20)(예를 들어, OLED 디스플레이)는 좌석, 테이블, 루프 라이너, 바닥, 창문(또는 창문이 없거나 창문이 거의 없는 차량, 벽) 또는 차량 캐빈의 다른 측면에 통합될 수 있다. 디스플레이(20)가 수동 디스플레이를 나타낼 때, 디스플레이(20)는 또한 수동 디스플레이(20) 상에 이미지를 투사하거나 재생성할 수 있는 프로젝터 또는 다른 이미지 투사 디바이스를 포함할 수 있다. 게다가, 디스플레이(20)는 (속도, 분당 회전수, 엔진 온도 등을 도시하는) 물리적 계기판을 가상으로 나타내는 운전자측 대시 보드에 통합된 디스플레이를 포함할 수 있다.
디스플레이(20)는 또한 차량(8)이 자율인 차량(8)과 유선 또는 무선 통신하는 디스플레이를 나타낼 수 있다. 디스플레이(20)는 예를 들어 랩탑 컴퓨터, 헤드 업 디스플레이, 헤드 마운트 디스플레이, 증강 현실 컴퓨팅 디바이스 또는 디스플레이("스마트 글래스"와 같은), 가상 현실 컴퓨팅 디바이스 또는 디스플레이, 모바일 폰(소위 "스마트 폰" 포함), 태블릿 컴퓨터, 게임 시스템, 또는 차량(8)에 통합 된 디스플레이의 확장으로서 또는 그 대신에 작용할 수 있는 다른 유형의 컴퓨팅 디바이스와 같은 컴퓨팅 디바이스를 나타낼 수 있다.
사용자 인터페이스(22)는 사용자가 차량(8)의 다양한 기능을 제어하기 위해 인터페이스할 수 있는 임의의 유형의 물리적 또는 가상 인터페이스를 나타낼 수 있다. 사용자 인터페이스(22)는 물리적 버튼, 노브, 슬라이더 또는 다른 물리적 제어 도구를 포함할 수 있다. 사용자 인터페이스(22)는 또한 차량(8)의 탑승자가 일 예로서 터치 감지 스크린을 통해 또는 터치리스 인터페이스를 통해 가상 버튼, 노브, 슬라이더 또는 다른 가상 인터페이스 요소와 상호 작용하는 가상 인터페이스를 포함할 수 있다. 탑승자는 사용자 인터페이스(22)와 인터페이스하여, 차량(8)내의 온도, 차량(8)에 의한 오디오 재생, 차량(8)에 의한 비디오 재생, 차량(8)을 통한 전송(핸드폰 호출과 같은), 또는 차량(8(에 의해 수행될 수 있는 임의의 다른 동작 중 하나 이상을 제어할 수 있다.
사용자 인터페이스(22)는 또한 차량(8)에 통합된 디스플레이의 확장으로서 또는 대신하여 작용할 때 디스플레이(20)로 확장된 인터페이스를 나타낼 수 있다. 즉, 사용자 인터페이스(22)는 헤드-업 디스플레이(HUD), 증강 현실 컴퓨팅 디바이스, 가상 현실 컴퓨팅 디바이스 또는 디스플레이, 태블릿 컴퓨터, 또는 위에서 나열된 상이한 유형의 확장 디스플레이 중 임의의 다른 것을 통해 제시된 가상 인터페이스를 포함할 수 있다.
차량(8)의 맥락에서, 사용자 인터페이스(22)는 차량(8)을 수동 또는 반수동으로 제어하기 위해 사용된 물리적 요소를 더 나타낼 수 있다. 예를 들어, 사용자 인터페이스(22)는 차량(8)의 주행 방향을 제어하기 위한 하나 이상의 핸들, 차량(8)의 주행 속도를 제어하기 위한 하나 이상의 페달, 하나 이상의 핸드 브레이크 등을 포함할 수 있다.
도 1의 예에서, 프로세서(15), GPU(14), 시스템 메모리(16), 디스플레이(20) 및 UI(22)는 자동차 맥락에서 헤드 유닛(24)(또는 달리 말하면, "차량 헤드 유닛(24)")으로 지칭되는 것을 적어도 부분적으로 통칭하여 나타낼 수 있다. 헤드 유닛(24)은 차량(8)의 다양한 양태와 인터페이스할 수 있고 및/또는 탑승자 및/또는 차량(8)에 관한 정보를 제공할 수 있는 임의의 통합 또는 별도의 컴퓨팅 디바이스를 나타낼 수 있다(이러한 헤드 유닛은 "인포테인먼트 유닛" 또는 "인포테인먼트 시스템"으로 지칭될 수 있음).
도 1의 예에 더 도시된 바와 같이, 차량(8)은 다수의 상이한 차량 시스템(26A-26N)("차량 시스템(26)")을 포함할 수 있다. 차량 시스템(26)은 HVAC(난방, 환기, 공조) 시스템 또는 온도 조절 시스템(예를 들어, HVAC 시스템 외에 난방 및/또는 냉방 시트를 포함할 수 있음)(둘 중 하나 또는 둘 모두 본 명세서에서 온도 시스템으로 지칭될 수 있음), 조명 시스템(내부 및/또는 외부 조명 제공용), 좌석 제어 시스템(탑승자 좌석의 위치 조정용), 미러 제어 시스템(백미러, 사이드 미러, 바이저 미러를 포함하여 내부 및/또는 외부 거울 제어용), 전면 유리창 와이퍼 제어 시스템, 엔터테인먼트 시스템(무선 재생, 비디오 재생, 이미지 디스플레이용), 안전 보조 시스템 (주차 지원, 백업 지원용), 주행 모드 시스템(서스펜션, 변속기 제어용), 선/문(sun/moon) 루프 제어 시스템(선 루프 및/또는 문 루프 제어용), 및 헤드 유닛(24)과 같은 헤드 유닛을 통해 제어할 수 있는 임의의 다른 유형의 차량 시스템을 포함할 수 있다. 차량 시스템(26)의 예는 전술한 차량 시스템(26) 중 임의의 예를 제어할 수 있는 전자 제어 유닛(ECU)을 포함할 수 있다.
헤드 유닛(24)은 도 1에 도시된 하나 이상의 메시지를 차량 시스템(26)에 커맨드("CS")(25A-25N)로서 발행하여 하나 이상의 차량 시스템(26)의 동작 상태를 변경할 수 있다. 동일한 제조업체의 다른 차량 모델뿐만 아니라 다른 제조업체의 차량 모델 사이에 다양한 차량 시스템(26)(기능 및 작동 측면에서)을 고려하면, 헤드 유닛(24)은 커맨드 세트의 수동 구성에 시간이 많이 걸리고 비용이 많이 들고 오류가 발생하기 쉽기 때문에 일반적으로 차량 시스템(26)의 최고 비율을 제어하는 커맨드(25A-25N)를 출력하도록 구성될 수 있다.
또한, 헤드 유닛(24)은 차량(8)에 사용자 관리 서비스를 제공하도록 구성된 제1 운영 체제("OS")(30)를 실행할 수 있다. 제1 OS(30)는 제2 OS(31)와 같이 다른 운영 체제와 인터페이스하기 위한 API(29)와 같은 인터페이스를 포함할 수 있다. 헤드 유닛(24)은 CAN(control area network) 프로토콜과 같은 제어 버스 프로토콜에 따라 메시지를 출력하도록 구성된 제2 OS(31)를 추가로 실행할 수 있다. 제2 OS(31)와 같은 헤드 유닛의 운영 체제는 CAN 프로토콜 또는 다른 표준(예를 들어, 공개 또는 독점) 제어 버스 프로토콜을 통해 차량 시스템(26)과 통신하도록 정적으로 구성(즉, "하드 코딩")될 수 있다. 즉, 제조업체는 제2 OS(31)가 제어 버스를 통해 각각의 차량 시스템(26)과 인터페이스할 수 있도록 제2 OS(31)를 수동으로 프로그래밍할 수 있다(이는 설명의 편의를 위해 도 1의 예에 도시되지 않음).
각각의 차량 시스템(26)과 정확하게 인터페이스하도록 운영 체제를 프로그래밍하는 것은 시간 소모적일 수 있고 차량 시스템(26)과의 정확한 상호 운용성을 보장하기 위해 상당한 테스트를 요구할 수 있다. 예시를 위해, 제조업체는 다양한 벤더로부터 차량 시스템(26)을 공급할 수 있는데, 이는 차량 특성의 상태를 전달하고 다수의 상이한 제어 버스 프로토콜에 따라 제어되는 차량 시스템(26)을 제공할 수 있다. 제조업체는 단일 모델 내에서도 상이한 제어 버스 프로토콜(예를 들어, 동일 모델의 상이한 트림 레벨 사이)에 따라 통신하는 차량 시스템(26)을 소싱해야 할 수 있다. 결과적으로, 제조업체는 둘 이상의 상이한 버전의 운영 체제를 생성할 수 있으며, 이들 각각은 상이한 제어 버스 프로토콜을 통해 차량 시스템(26)과 통신하도록 개별적으로 하드 코딩된다. 게다가 제어 버스 프로토콜에 대한 임의의 변경은 최신 버전의 제어 버스 프로토콜을 지원하도록 운영 체제를 하드 코딩하도록 제조업체에서 운영 체제를 업데이트할 수 있는데, 이는 제조업체가 새로운 또는 변경되는 제어 버스 프로토콜을 지원할 수 있는 능력을 잠재적으로 저하시키고 이로 인해 차량(8)이 차량(8)의 안전성, 편리성 및 다른 측면을 향상시키는 업그레이드를 잠재적으로 받지 못하게 할 수 있다.
본 개시에 설명된 기술의 다양한 양태에 따르면, 운영 체제(예를 들어, 제1 OS(30))는 사용자 관리 서비스를 제공하기 위해 차량 내의 다른 운영 체제(예를 들어, 제2 OS(31))와 메시지를 전달(통신)하기 위한 API와 같은 인터페이스를 제공할 수 있다. 위에서 언급한 바와같이, 차량 시스템 버스들은 헤드 유닛(24)("차량 헤드 유닛(24)"으로도 지칭될 수 있음)과 차량의 하나 이상의 시스템(예를 들어, 차량 시스템(26))사이에서 커맨드(25A-25N)가 전달되는 상이한 독점 및 공개 표준을 따를 수 있다. 차량 헤드 유닛(24)은 차량(8)에 사용자 관리 서비스를 제공하도록균일한 메시지를 지원하는 제1 OS(30) 및 복수의 로컬 제어 버스 프로토콜 중 특정 로컬 제어 버스 프로토콜에 따라 지정된 바와 같이 차량 시스템 버스들(26)을 통해 전달하기 위한 로컬 제어 메시지를 지원할 수 있는 제2 OS(31)를 실행할 수 있다. 특정 로컬 제어 메시지를 지원하기 위해 제1 OS(30)를 하드 코딩하는 대신에, 본 기술의 다양한 양태는 차량 헤드 유닛(24)의 제1 OS(30)가 API와 같은 인터페이스를 제공하여, 제1 OS(30)에 의한 차량(8)에 대한 사용자 관리 서비스의 제공을 용이하게 하기 위해 제1 OS(30)와 제2 OS(31)사이에서 메시지 전달을 가능하게 할 수 있다. 로컬 제어 메시지는 DBC 포맷, Kayak CAN 정의(KCD) 포맷 또는 다른 포맷 중 하나에 따라 포맷될 수 있다.
동작에서, 프로세서(15)는 차량(8)에 대한 사용자 관리 서비스를 제공하기 위해 제1 OS(30)를 실행할 수 있다. 일부 예에서, 프로세서(15)는 제2 OS(31)를 통해 하나 이상의 차량 시스템(26)의 설정을 변경하여 특정 사용자의 선호도를 반영하도록 제1 OS(30)를 실행하여 하나 이상의 차량 시스템(26)을 제어할 수 있다. 예를 들어, 제1 OS(30)는 API(29)와 같은 인터페이스를 통해 메시지를 제2 OS(31)로 제공할 수 있다.
일부 예에서, 프로세서(15)는 제1 OS(30)의 하나 이상의 스레드 및 제2 OS(31)의 하나 이상의 스레드를 실행할 수 있다. 일부 예에서, 개별 프로세서는 제1 OS(30)의 하나 이상의 스레드를 실행할 수 있고, 개별 프로세서는 제2 OS(31)의 하나 이상의 스레드를 실행할 수 있다. 일부 예에서, 제2 OS(31)는 HAL(28)을 제공하도록 구성될 수 있다. HAL(28)은 API(29)와 차량 시스템(26)(제어 버스를 포함하고, 도 1의 예에 도시되지 않음) 사이에 소프트웨어 심(shim) 계층으로 지칭될 수 있는 것을 제공할 수 있다. 프로세서(15)는 HAL(28)과 관련된 하나 이상의 스레드를 포함하여, 제2 OS(31)를 나타내는 하나 이상의 스레드를 실행할 수 있다. 프로세서(15)는 각각 제1 OS(30) 또는 제2 OS(31)의 하나 이상의 스레드와 관련된 하나 이상의 커맨드의 형태로 시스템 메모리(16)로부터 제1 OS(30)(API(29) 포함) 또는 제2 OS(31)(HAL 28 포함)를 검색하여, 커맨드들을 실행 전에 로컬 메모리(예를 들어, 설명의 편의를 위해 도 1의 예에 도시되지 않은 계층 1(L1), 계층 2(L2) 및/또는 계층 3(L3) 캐시)에 로딩할 수 있다. 이와 같이, API(29), 제1 OS(30), HAL(28) 및 제2 OS(31)는 프로세서(15)에 의한 실행을 나타내기 위해 점선을 사용하여 프로세서(15)에 포함되는 것으로 도시되는 한편, API(29), 제1 OS(30), HAL(28) 및 제2 OS(31)의 장기 저장을 나타내기 위해 실선을 사용하여 시스템 메모리(16)에 포함되는 것으로도 도시되어 있다. 프로세서(15)에 의해 실행되는 것으로 도시되어 있지만, HAL(28)은 또한 전용 회로 또는 하드웨어 로직을 사용하여 구현될 수 있다.
임의의 경우에, HAL(28)은 API(29)와 인터페이스하여, 제1 OS(30)가 제2 OS(31)를 통해 차량 시스템(26)과 인터페이스하도록 할 수 있다. 이와 같이, 제1 OS(30)는 사용자 관리와 관련된 메시지를 제2 OS(31)로 제공할 수 있고, 제2 OS(31)는 제2 OS(31)에 의해 지원되는 제어 버스 프로토콜을 따르는 커맨드(25)를 생성하여 하나 이상의 차량 시스템(26)을 제어할 수 있다. HAL(28)은 메시지를 수신(또는 일부 경우에는 인터셉트)하고, 일부 예에서 그러한 변환(translation)을 요청하는 제2 OS(31)없이(그리고 이와 관련하여 제2 OS(31)의 관점에서 투명하게), 메시지를 변환하여 로컬 제어 버스를 따르는 로컬 메시지를 획득할 수 있다.
일부 예에서, HAL(28)은 API(29)로부터 메시지의 제1 표현을 수신할 수 있으며, 이는 하나 이상의 차량 시스템(26)의 동작 상태를 변경하거나 하나 이상의 차량 시스템(26)의 동작 상태를 주어진 사용자의 선호도에 맞추기 위해 하나 이상의 차량 시스템(26)의 동작 상태 변경을 개시하기 위한 요청과 같은 사용자 관리와 관련된 정보를 포함할 수 있다.
HAL(28)은 메시지 내의 바이트 값을 재배열하거나 변환하여, 제어 버스 프로토콜을 따르는 로컬 제어 메시지를 얻기 위해 메시지를 변환할 수 있다. 로컬 제어 메시지는 이와 같이 메시지의 제2 표현을 포함할 수 있다. HAL(28)은 프로세서(15) 및 차량 시스템(26)에 연결된 제어 버스를 통해, 로컬 제어 메시지를 전송하여 하나 이상의 차량 시스템(26)의 동작 상태 변경을 개시할 수 있다.
HAL(28)은 마찬가지로 동작 상태(27A-27N)(도 1에서 "ST 27A-27N"으로 도시된 동작 상태(27))를 포함하는 로컬 메시지를 차량 시스템(26)으로부터 수신할 수 있다(또는 일부 경우 제2 OS(31) 및 차량 시스템(26)의 관점에서 투명하게 가로 챌 수 있다). 로컬 제어 메시지는 로컬 제어 버스 프로토콜을 따를 수 있다. HAL(28)은 로컬 제어 메시지를 변환(translate)하여 제1 OS(30)의 API(29)에 의해 지원되는 메시지를 획득할 수 있다. 위에서 언급한 바와 같이, HAL(28)은 기본 하드웨어를 추상화하는 것의 일부로서(즉, 심(shim) 소프트웨어 계층을 제공하는 것의 일부로서) 이 변환을 제공하여, 다양한 상이한 하드웨어 플랫폼에 대해 제1 OS(30)의 보다 간단한 개발 및 설치를 잠재적으로 가능하게 한다. HAL(28)은 이전에 전송된 메시지에 의해 요청된 동작 상태 변경의 확인을 획득할 수 메시지를 API(29)에 제공할 수 있다.
위에서 언급한 바와 같이, HAL(28)은 일 예에서, 하나 이상의 차량 시스템(26)의 동작 상태를 변경하기 위해 사용자로부터 디스플레이(20)에 의해 제시되는 GUI를 통해 수신된 입력에 응답하여, 제1 OS(30)의 API(29)로부터의 메시지를 처리하도록 구성된 유닛을 나타낼 수 있다. HAL(28)은 또한 동작 상태(27)와 같은 다른 입력에 응답하여 자동으로 생성되는 제1 OS(30)의 API(29)로부터의 출력을 처리할 수 있다. 출력은 동작 상태 변경을 수행하거나 동작 상태 변경을 요청하기 위해 제1 OS(30)에 의해 발행된 메시지를 지칭할 수 있다.
일부 예에서, 제1 OS(30) 또는 제2 OS(31)는 인증의 형태에 기초하여 하나 이상의 차량 시스템(26)의 동작 상태의 변경을 개시하도록 결정할 수 있다. 예를 들어, 제1 OS(30) 또는 제2 OS(31)는 사용자를 키포브(key fob, 전자 열쇠), 지문, 얼굴 또는 음성과 연관시킬 수 있다. 일부 예에서, 차량 시스템들(26) 중 하나는 인증 시스템을 나타낼 수 있다. 다른 예에서, 헤드 유닛(24)은 인증 시스템을 포함할 수 있다. 인증 시스템은 사용되는 키포브, 사용자의 지문, 사용자의 얼굴 이미지 또는 사용자의 음성 샘플과 같은 인증 인자(본 명세서에서는 인증 형태라고도 함)를 결정할 수 있다. 인증 시스템은 인증 인자를 나타내는 메시지를 제2 OS(31)에 제공할 수 있다.
일부 예에서, HAL(28)은 인증 인자를 나타내는 메시지를 API(29)에 제공할 수 있다. 제1 OS(30)는 인증 인자에 기초하여 현재 사용자가 "마지막 활성 사용자"가 아닌지 결정하고, 현재 사용자가 마지막 활성 사용자가 아니라는 것에 기초하여 API(29)를 통해 HAL (28)에 메시지를 제공하여 하나 이상의 차량 시스템(26)에서 변경을 요청할 수 있다. 마지막 활성 사용자는 (자동차 엔진이 꺼지거나 자동차가 멈추기 전에) 자동차를 사용한 마지막 사용자일 수 있다. 메시지는 현재 사용자에 대한 하나 이상의 차량 시스템(26)의 하나 이상의 선호 설정을 포함할 수 있다.
HAL(28)은 사용자 관리 서비스가 주어진 시간에서 이용 가능한지를 결정할 수 있다. 예를 들어, HAL(28)은 차량이 이동하는 동안 사용자 설정의 변경이 이용 가능하지 않을 수 있거나 또는 안전상의 이유로 사용자 설정의 변경이 이용 가능하도록 차량이 주차되어 있어야 한다고 결정할 수 있다. 일부 예에서, HAL(28)은 특정 사용자 설정이 변경될 수 있다고 결정할 수 있지만, 다른 것들은 차량의 상태에 근거하지 않는다. 예를 들어, HAL(28)은 차량이 이동할 때 상대적인 좌석 위치는 변하지 않을 수 있다고 결정할 수 있지만, 온도 제어는 변할 수 있다.
도 2는 도 1의 헤드 유닛의 예를 보다 상세하게 나타내는 블록도이다. 도 2의 예에 도시된 헤드 유닛(24A)은 도 1에 도시된 헤드 유닛(24)의 일 예이다. 헤드 유닛(24A)은 자동차 서비스(50), 예를 들어 사용자 관리 서비스를 위한 실행 환경을 제공하는 제1 OS(30)(및 API(29))를 실행할 수 있다.
헤드 유닛(24A)은 또한 2개의 상이한 HAL(28A 및 28B)을 실행할 수 있다. 차량 HAL(28A)은 변환 서비스(52)를 실행할 수 있으며, 이는 본 개시에 기술된 기술의 다양한 양태에 따라 API(29)로부터의 메시지와 로컬 제어 메시지 사이의 변환을 수행할 수 있다. CAN(Controller Area Network) 버스 HAL(28B)는 로컬 제어 메시지를 범용 시스템 버스(USB) 신호로 그리고 USB 신호를 로컬 제어 메시지로 변환하여 하드웨어와 제1 OS(30) 사이에 또 다른 추상화 계층을 제공하도록 구성된 유닛을 나타낼 수 있다.
헤드 유닛(24A)은 또한 USB CAN 인터페이스(58) 및 게이트웨이(60)를 노출시키는 하나 이상의 프로세서, 고정 논리 회로, 전용 신호 프로세서, 전용 제어 프로세서(전용 제어 버스 프로세서와 같은)등과 함께 물리적 USB 인터페이스인 USB(56)를 포함할 수 있다. USB CAN 인터페이스(58)는 USB 포트를 통해 CAN(61)에 대한 액세스를 제공하도록 구성된 유닛을 나타낼 수 있다. 게이트웨이(60)는 CAN(61)에 대한 액세스를 제어하는 제어 버스 게이트웨이를 노출시키도록 구성된 유닛을 나타내고, 특정 조건이 존재하는 경우(예를 들어, 잘못된 CAN 신호의 삭제(dropping) 등) CAN(61)에 대한 액세스를 제한할 수 있는 방화벽 또는 다른 유형의 디바이스를 나타낼 수 있다. 차량 전기 시스템 또는 서브 시스템을 제어할 수 있는 다수의 전자 제어 유닛(ECU)(62A-62N)은 CAN(61)에 통신 가능하게 결합될 수 있다.
도 3은 본 개시의 기술에 따른 성공적인 사용자 전환(switch)의 예를 도시한 흐름도이다. 이 예에서, 현재 사용자는 사용자(10)로 설정될 수 있고 기존 사용자는 사용자(0, 10 및 11)를 포함할 수 있다. 사용자 인터페이스("UI")(100)(APP UI)는 사용자(10)에서 사용자(11)로 사용자 전환을 요청하는 메시지(예를 들어, SwitchToUser(11, 리스너))를 CarUserManager 애플리케이션(APP CARUM)(102)으로 전송할 수 있다(202). 일부 예에서, 메시지는 사용자 입력에 기초할 수 있다. 다른 예에서, 메시지는 인증 인자에 기초할 수 있다. 일부 예에서, 메시지는 하나 이상의 차량 시스템(26)의 동작 상태의 설정에 대한 사용자(11)의 선호도를 포함할 수 있다. UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(204). CarUserManager 애플리케이션(102)은 사용자(10)로부터 사용자(11)로의 전환을 요청하는 메시지(예컨대, SwitchToUser(11, 리스너))를 CarUserService(CAR CARUS)(104)로 전송할 수 있다(206). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자 전환 권한이 인에이블(활성화)되었는지를 결정할 수 있다(208). 권한이 인에이블된 경우, CarUserService(104)는 사용자(10)로부터 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SwitchUser(10, 11,(0, 10, 11), 리스너))를 UserHalService(CAR UHS)(106)로 전송할 수 있다(210). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 사용자(10)로부터 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SWITCH_USER_REQUEST : 10, 11(0, 10, 11))를 VehicleHAL(OEM VHAL)(108)로 전송할 수 있다(212). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 예를 들어, VehicleHAL(108) 또는 제2 OS(31)에서 사용자(10)를 사용자(11)로 내부적으로 전환할 수 있다(213). 예를 들어, VehicleHAL(108)은 하나 이상의 차량 시스템(26)에 로컬 커맨드를 발행하여 사용자(11)의 선호도와 일치하도록 하나 이상의 동작 상태를 변경할 수 있다. VehicleHAL은 차량상의 사용자의 전환을 나타내는 메시지(예를 들어, SWITCH_USER_REQUEST:OK, -1)를 UserHalService(106)로 다시 제공할 수 있다(214). UserHalService(106)는 제1 OS(30)에서 사용자의 변경이 양호함(okay)을 나타내는 메시지(예를 들어, result(ok))를 CarUserService(104)로 전송할 수 있다(216). CarUserService(104)는 IActivityManager(110)(제1 OS(30)의 예일 수 있음)로 사용자에게 전환하기 위한 메시지(예를 들어, SwitchUser(11))를 제공할 수 있다(218). IActivityManager(110)는 제1 OS(30)의 사용자를 사용자(11)로 전환하고(219), 사용자가 사용자(11)로 변경되었음을 나타내는 메시지(예를 들어, true)를 CarUserService(104)로 다시 제공할 수 있다(220).
일부 예에서, CarUserService(104)는 사용자(10)로부터 사용자(11)로의 전환이 UserHalService(106)에 대해 이루어졌음을 확인하는 포스트(post) 요청(예를 들어, postSwitchUser(ok, 10, 11,(0, 10, 11)))을 전송할 수 있고(222), UserHalService(106)는 사용자(10)에서 사용자(11)로의 전환이 이루어졌음을 확인하는 메시지(예를 들어, SWITCH_USER_POST_REQUEST:OK, 10, 11,(0, 10, 11))를 VehicleHAL(108)로 전송한다(224). 일부 예에서, 포스트 요청은 onUserSwitch() 콜백처럼 작동하며 ACTION_LOCKED_BOOT_COMPLETED으로 전송된다. 또한, CarUserService(104)는 사용자의 변경이 이루어졌음을 나타내는 메시지(예를 들어, listener.onResult(result=ok))를 UI(100)로 전송할 수 있다(226). 일부 예에서, UI(100)는 사용자의 변경이 이루어졌다는 표시를 사용자에게 제공할 수 있다(단순화를 위해 미도시됨). 예를 들어, UI(100)는 "다시 온 걸 환영해, 존" 또는 "차량 시스템이 당신의 선호에 맞게 변경되었습니다, 메리"등과 같은 메시지를 디스플레이할 수 있다. 일부 예에서, UI(100)는 변경이 이루어졌다는 청각 표시를 사용자에게 제공할 수 있다.
도 4는 본 개시의 기술에 따른 제2 OS(31)에 기초한 실패한 사용자 전환의 예를 도시한 흐름도이다. 이 예에서, 현재 사용자는 사용자(10)이고 기존 사용자는 사용자(0, 10 및 11)를 포함할 수 있다. UI(100)는 사용자(10)로부터 사용자(11)로 사용자를 전환하도록 요청하는 메시지(예를 들어, SwitchToUser(11, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(228). CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(230). CarUserManager 애플리케이션(102)은 사용자(10)에서 사용자(11)로 전환을 요청하는 메시지(예를 들어, SwitchToUser(11, 리스너))를 CarUserService(104)로 전송할 수 있다(232). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자를 전환하기 위한 권한이 인에이블되었는지를 결정할 수 있다(234). 권한이 인에이블된 경우, CarUserService(104)는 사용자(10)에서 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SwitchUser(10, 11,(0, 10, 11), 리스너))를 UserHalService(106)로 전송할 수 있다(236). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 사용자(10)에서 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SWITCH_USER_REQUEST:10, 11(0, 10, 11))를 VehicleHAL(108)로 전송할 수 있다(238). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 사용자(10)를 사용자(11)로 전환하라는 요청을 거부하고, 사용자 전환 요청의 거부(예를 들어, SWITCH_USER_REQUEST:FAIL, 42)를 나타내는 메시지를 UserHalService(106)에 다시 제공할 수 있다(240). 예를 들어, VehicleHAL(108)은 차량이 이동하고 있다고 결정하여 사용자의 전환를 방지할 수 있다. UserHalService(106)는 사용자 변경 요청이 거부되었음을 나타내는 메시지(예를 들어, Request(FAIL, 42))를 CarUserService(104)에 전송할 수 있다(242). CarUserService(104)는 사용자 전환이 발생하지 않았음을 나타내는 메시지(예를 들어, listener.onResult(result=OEM_FAIL, 오류=42))를 UI(100)에 제공할 수 있다(244). 일부 예에서, UI(100)는 전환이 발생하지 않았다는 표시를 사용자(11)에게 제공할 수 있다(245). 예를 들어, UI(100)는 차량이 이동하는 등의 이유로 인해 사용자의 변경이 허용되지 않는다는 오류 메시지 또는 메시지를 디스플레이할 수 있다. 일부 예에서, UI(100)는 사용자 변경이 발생하지 않았다는 청각적 표시를 제공할 수 있다.
도 5는 본 개시의 기술에 따른 제1 OS(30)에 기초한 실패한 사용자 전환의 예를 도시한 흐름도이다. 이 예에서, 현재 사용자는 사용자(10)로 설정될 수 있고 기존 사용자는 사용자(0, 10 및 11)를 포함할 수 있다. UI(100)는 사용자(10)로부터 사용자(11)로 사용자를 전환할 것을 요청하는 메시지(예컨대, SwitchToUser(11, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(246). CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(248). CarUserManager 애플리케이션(102)은 사용자(10)로부터 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SwitchToUser(11, 리스너))를 CarUserService(104)로 전송할 수 있다(250). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자를 전환하기 위한 권한이 인에이블되었는지를 결정할 수 있다(252). 권한이 인에이블된 경우, CarUserService(104)는 사용자(10)에서 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SwitchUser(10, 11,(0, 10, 11), 리스너))를 UserHalService(106)로 전송할 수 있다(254). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 사용자(10)에서 사용자(11)로의 전환을 요청하는 메시지(예를 들어, SWITCH_USER_REQUEST:10, 11(0, 10, 11))를 VehicleHAL(108)에 전송할 수 있다(256). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 VehicleHAL(108) 또는 제2 OS(31)에서 내부적으로 사용자(10)를 사용자 11로 전환하고(257), 차량상의 사용자 전환이 양호함(okay)을 나타내는 메시지(예컨대, SWITCH_USER_REQUEST:OK, -1)를 UserHalService(106)로 다시 제공할 수 있다(258). UserHalService(106)는 제1 OS(30)에서 사용자의 변경이 양호함을 나타내는 메시지(예를 들어, Result(ok))를 CarUserService(104)로 전송할 수 있다(260). CarUserService(104)는 사용자(11)로 전환하라는 메시지(예를 들어, SwitchUser(11))를 (제1 OS(30)의 예일 수 있는) IActivityManager(110)로 제공할 수 있다(262). IActivityManager(110)는 제1 OS(30)에서 사용자 변경에 실패할 수 있고(단순화를 위해 미도시됨), 사용자가 변경되지 않았음을 나타내는 메시지(예를 들어, false)를 CarUserService(104)로 다시 제공할 수 있다(264). CarUserService(104)는 사용자(10)로부터 사용자(11)로의 전환이 이루어지지 않았음을 확인하는 포스트 요청(예를 들어, postSwitchUser(fail, 10, 10,(0, 10, 10)))을 UserHalService(106)로 전송할 수 있고(266), UserHalService(106)는 남아있는 사용자(10)를 나타내는 메시지(예를 들어, SWITCH_USER_POST_REQUEST:10, 11,(0, 10, 10))를 VehicleHAL(108)로 전송한다(268). VehicleHAL(108)은 VehicleHAL(108) 또는 제2 OS(31)에서 내부적으로 사용자를 사용자(10)로 다시 변경할 수 있다(269). CarUserService(104)는 사용자의 전환이 발생하지 않았음을 나타내는 메시지(예를 들어, listener.onResult(result=ANDROID FAIL))를 UI(100)에 제공할 수 있다(270). 일부 예에서, UI(100)는 전환이 발생하지 않았다는 표시(단순화를 위해 미도시됨)를 사용자(11)에게 제공할 수 있다. 예를 들어, UI(100)는 차량이 이동하는 등의 이유로 인해 사용자의 변경이 허용되지 않는다는 오류 메시지 또는 메시지를 디스플레이할 수 있다. 일부 예에서, UI(100)는 사용자의 변경이 발생하지 않았다는 청각적 표시를 제공할 수 있다.
도 6은 본 개시의 기술에 따른 성공적인 사용자 생성의 예를 도시한 흐름도이다. 사용자 인터페이스("UI")(APP UI)(100)는 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(272). 메시지는 (일반 사용자 또는 게스트 사용자와 같은) 사용자 유형 및 사용자 이름을 포함할 수 있다. 일부 예에서, 게스트 사용자는 일반(regular) 사용자와 다른 차량 시스템(26)을 제어하는 능력을 가질 수 있다. 예를 들어, 일반 사용자는 일반 사용자의 프로필을 기반으로 할 수 있으므로 게스트 사용자는 게스트 사용자의 프로필에 기초하여 많은 차량 시스템(26)을 구성하지 못할 수 있다. 일부 예에서, 메시지는 초기 사용자 생성 요청일 수 있다. 예를 들어, 차량이 처음에 시동될 때(처음으로 또는 차량 판매시), UI(100)는 초기 사용자를 생성하려고 할 수 있다. 사용자 프로필은 다양한 차량 시스템(26A-26N)의 설정에 대한 사용자 선호도를 포함할 수 있다.
또한, 메시지는 하나 이상의 차량 시스템(26)의 동작 상태에 대한 선호 설정을 포함할 수 있다. UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(274). CarUserManager 애플리케이션(102)은 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 CarUserService(104)로 전송할 수 있다(276). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 IUserManager(112)로 전송할 수 있다(278). IUserManager(112)는 사용자를 생성하기 위한 권한이 인에이블되었는지 여부를 결정할 수 있다(280). 권한이 인에이블된 경우, IUserManager(112)는 새로운 사용자가 생성될 수 있고 새로운 사용자 ID가 사용자(12)라는 것을 나타내는 메시지(예를 들어, UserInfo(info.id-12))를 CarUserService(104)로 전송할 수 있다(282). CarUserService(104)는 새로운 사용자(12)를 생성하도록 요청하는 메시지(예를 들어, CreateUser(12, "TheDude", userType, 플래그, 리스너))를 UserHalService(106)로 전송할 수 있다(284). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 새로운 사용자(12)를 생성하기 위해 메시지(예를 들어, CREATE_USER_REQUEST:12, 플래그, "userType, TheDude")를 VehicleHAL(108)로 전송할 수 있다(286). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 VehicleHAL(108) 또는 제2 OS(31)에서 새로운 사용자(12)를 생성하고, 새로운 사용자 정보(예를 들어, 사용자 ID, 사용자 이름, 사용자 유형, 및/또는 하나 이상의 차량 시스템(26)의 선호 설정)를 사용자 관리 데이터(35)에 저장할 수 있다(287). VehicleHAL(108)은 새로운 사용자(12)가 사용자 관리 데이터(35)에 생성되었음을 나타내는 메시지(예컨대, CREATE_USER_REQUEST:OK)를 UserHalService(106)로 제공할 수 있다(288). UserHalService(106)는 새로운 사용자(12)의 생성이 성공했음을 나타내는 메시지(예를 들어, Result(ok))를 CarUserService(104)로 전송할 수 있다(290). CarUserService(104)는 새로운 사용자(12)의 생성이 성공했음을 나타내는 메시지(예컨대, listener.onResult(result = ok, userId=12))를 UI(100)로 제공할 수 있다(292). 일부 예에서, UI(100)는 새로운 사용자의 생성이 성공했다는 표시(단순화를 위해 미도시됨)를 사용자(12)에게 제공할 수 있다. 예를 들어, UI(100)는 새로운 사용자의 생성이 성공했음을 나타내는 메시지를 디스플레이할 수 있거나 UI(100)는 새로운 사용자의 생성이 성공했다는 청각적 표시를 제공할 수 있다.
도 7은 본 개시의 기술에 따른 제1 OS(30)에 기초한 실패한 사용자 생성의 예를 도시하는 흐름도이다. 사용자 인터페이스("UI")(APP UI)(100)는 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(294). UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(296). CarUserManager 애플리케이션(102)은 새로운 사용자(298)를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 CarUserService(104)에 전송할 수 있다(298). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 IUserManager(112)로 전송할 수 있다(300). IUserManager(112)는 사용자를 생성하기 위한 권한이 인에이블되었는지 여부를 결정할 수 있다(302). 권한이 인에이블되지 않은 경우, IUserManager(112)는 새로운 사용자가 생성될 수 없음을 나타내는 메시지(예를 들어, null)를 CarUserService(104)로 전송할 수 있다(304). 이 경우, CarUserService(104)는 VehicleHAL(108)을 호출할 수 없다. CarUserService(104)는 새로운 사용자의 생성이 실패했음을 나타내는 메시지(예를 들어, listener.onResult(result=ANDROID_FAIL))를 UI(100)로 제공할 수 있다(306). UI(100)는 새로운 사용자의 생성이 실패했다는 표시를 제공할 수 있다(307). 예를 들어, UI(100)는 새로운 사용자의 생성이 실패했다는 메시지를 디스플레이하거나 청각적 표시를 제공할 수 있다.
도 8은 본 개시의 기술에 따른 제2 OS(31)에 기초한 실패한 사용자 생성의 예를 도시한 흐름도이다. 사용자 인터페이스("UI")(APP UI)(100)는 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(308). UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(310). CarUserManager 애플리케이션(102)은 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 CarUserService(104)로 전송할 수 있다(312). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 새로운 사용자를 생성하도록 요청하는 메시지(예를 들어, CreateUser("TheDude", userType, 플래그, 리스너))를 IUserManager(112)에 전송할 수 있다(314). IUserManager(112)는 제1 OS(30)의 예를 나타낼 수 있다. IUserManager(112)는 사용자를 생성하기 위한 권한이 인에이블되었는지 여부를 결정할 수 있다(316). 권한이 인에이블된 경우, IUserManager(112)는 IUserManager(112)에서 새로운 사용자, 예를 들어, 사용자(12)를 생성할 수 있다(단순화를 위해 미도시됨). IUserManager(112)는 새로운 사용자가 생성될 수 있고 새로운 사용자 ID가 사용자(12)라는 것을 나타내는 메시지(예를 들어, UserInfo(info.id=12))를 CarUserService(104)로 전송할 수 있다(318). CarUserService(104)는 새로운 사용자(12)의 생성을 요청하는 메시지(예를 들어, CreateUser(12, "TheDude", userType, 플래그, 리스너))를 UserHalService(106)로 전송할 수 있다(320). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 새로운 사용자(12)를 생성하기 위한 메시지(예를 들어, CREATE_USER_REQUEST:12, 플래그, "userType, TheDude")를 VehicleHAL(108)로 전송할 수 있다(322). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 사용자 관리 데이터(35)에 새로운 사용자(12)를 생성하는 것에 실패할 수 있다(323). VehicleHAL(108)은 사용자 관리 데이터(35)에 새로운 사용자(12)가 생성되지 않았음을 나타내는 메시지(예를 들어, CREATE_USER_REQUEST:FAIL, 42)를 UserHalService(106)로 제공할 수 있다(324). UserHalService(106)는 새로운 사용자(12)의 생성이 실패했음을 나타내는 메시지(예를 들어, Result(FAIL, 42))를 CarUserService(104)로 전송할 수 있다(326). CarUserService(104)는 사용자(12)를 제거하기 위한 메시지(예를 들어, removeUser(12))를 IUserManager(112)로 제공할 수 있다(328). IUserManager(112)는 사용자(12)를 제거할 수 있다(단순화를 위해 미도시됨). CarUserService(104)는 새로운 사용자(12)의 생성이 실패했음을 나타내는 메시지(예를 들어, listener.onResult(result=OEM_FAIL, 오류=42))를 UI(100)로 제공할 수 있다(330). UI(100)는 새로운 사용자의 생성이 실패했다는 표시(단순화를 위해 미도시됨)를 제공할 수 있다.
도 9는 본 개시의 기술에 따른 성공적인 사용자 제거의 예를 도시한 흐름도이다. 사용자 인터페이스("UI")(APP UI)(100)는 사용자(12)의 제거를 요청하는 메시지(예를 들어, removeUser(12, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(332). UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(334). CarUserManager 애플리케이션(102)은 사용자(12)의 제거를 요청하는 메시지(예를 들어, removeUser(12))를 CarUserService(104)로 전송할 수 있다(336). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자(12)를 제거하도록 요청하는 메시지(예를 들어, removeUser(12))를 IUserManager(112)로 전송할 수 있다(338). IUserManager(112)는 제1 OS(30)의 예를 나타낼 수 있다. IUserManager(112)는 사용자를 제거하기 위한 권한이 인에이블되었는지 여부를 결정할 수 있다(340). 권한이 인에이블된 경우, IUserManager(112)는 CarUserService(104)가 사용자를 제거할 수 있음을 나타내는 메시지(예를 들어, true)를 CarUserService(104)로 전송할 수 있다(342). CarUserService(104)는 사용자(12)의 제거를 요청하는 메시지(예를 들어, removeUser(12))를 UserHalService(106)로 전송할 수 있다(344). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 사용자(12)를 제거하기 위한 메시지(예를 들어, REMOVE_USER_REQUEST:12)를 VehicleHAL(108)로 전송할 수 있다(346). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 예를 들어, 사용자 관리 데이터(35)로부터 사용자(12)를 제거할 수 있다(347). VehicleHAL(108)은 사용자(12)가 제거되었음을 나타내는 메시지(예를 들어, REMOVE_USER_REQUEST:OK)를 UserHalService(106)로 제공할 수 있다(348). UserHalService(106)는 사용자(12)가 제거되었음을 나타내는 메시지(예를 들어, Result(ok))를 CarUserService(104)로 전송할 수 있다(350). CarUserService(104)는 또한 사용자(12)를 제거하기 위한 메시지(예를 들어, removeUser(12))를 IUserManager(112)로 전송할 수 있다(352). IUserManager(112)는 예를 들어 클라우드에 기반한 메모리(단순화를 위해 미도시됨)로부터 사용자(12)를 제거할 수 있다. CarUserService(104)는 또한 사용자(12)가 제거되었음을 나타내는 메시지를 UI(100)로 제공할 수 있다. UI는 디스플레이된 메시지 또는 청각적 표시(단순화를 위해 미도시됨)와 같이 사용자(12)가 제거되었다는 표시를 사용자에게 제공할 수 있다.
도 10은 본 개시의 기술에 따른 제1 OS(30)에 기초한 실패한 사용자 제거의 예를 도시하는 흐름도이다. UI(100)는 사용자, 예를 들어, 사용자(12)의 제거하도록 요청하는 메시지(예를 들어, removeUser(12, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(356). UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(358). CarUserManager 애플리케이션(102)은 사용자(12)의 제거하도록 요청하는 메시지(예를 들어, removeUser(12))를 CarUserService(104)로 전송할 수 있다(360). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자(12)를 제거하도록 요청하는 메시지(예를 들어, removeUser(12))를 IUserManager(112)로 전송할 수 있다(362). IUserManager(112)는 제1 OS(30)의 예를 나타낼 수 있다. IUserManager(112)는 사용자를 제거하기 위한 권한이 인에이블되었는지 여부를 결정할 수 있다(364). 권한이 인에이블되지 않은 경우, IUserManager(112)는 CarUserService(104)가 사용자를 제거할 수 없음을 나타내는 메시지(예를 들어, false)를 CarUserService(104)로 전송할 수 있다(366). 이 경우, CarUserService(104)는 VehicleHAL(108)을 호출하지 않을 수 있다. CarUserService(104)는 사용자(12)가 제거되지 않았음을 나타내는 메시지(예를 들어 listener.onResult(result=ANDROID_FAIL))를 UI(100)로 전송할 수 있다(368). UI(100)는 사용자(12)가 제거되지 않았다는 표시를 제공할 수 있다.
도 11은 본 개시의 기술에 따른 제2 OS(31)에 기초한 실패한 사용자 제거의 예를 도시한 흐름도이다. 사용자 인터페이스("UI")(APP UI)(100)는 사용자(12)를 제거하도록 요청하는 메시지(예를 들어, removeUser(12, 리스너))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(370). UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 메시지가 수신되었음을 UI(100)에 응답할 수 있다(372). CarUserManager 애플리케이션(102)은 사용자(12)를 제거하도록 요청하는 메시지(예를 들어, removeUser(12))를 CarUserService(104)로 전송할 수 있다(374). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자(12)를 제거하도록 요청하는 메시지(예를 들어, removeUser(12))를 IUserManager(112)로 전송할 수 있다(376). IUserManager(112)는 제1 OS30의 예를 나타낼 수 있다. IUserManager(112)는 사용자를 제거하는 권한이 인에이블되었는지 여부를 결정할 수 있다(378). 권한이 인에이블된 경우, IUserManager(112)는 CarUserService(104)가 사용자(12)를 제거할 수 있음을 나타내는 메시지(예를 들어, true)를 CarUserService(104)로 전송할 수 있다(380). CarUserService(104)는 사용자(12)를 제거하도록 요청하는 메시지(예를 들어, removeUser(12))를 UserHalService(106)로 전송할 수 있다(382). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 사용자(12)를 제거하기 위한 메시지(예를 들어, REMOVE_USER_REQ:12)를 VehicleHAL(108)로 전송할 수 있다(384). VehicleHAL(108)은 도 1 및 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 예를 들어, 사용자 관리 데이터(35)로부터 사용자(12)를 제거하는데 실패할 수 있다(385). 예를 들어, VehicleHAL(108)은 사용자(12)가 현재 사용자인 것으로 결정하고 현재 사용자를 제거하지 않을 수 있다. VehicleHAL(108)은 사용자(12)가 제거되지 않았다는 것을 나타내는 메시지(예를 들어, REMOVE_USER_REQ : FAIL, 42)를 UserHalService(106)로 제공할 수 있다(386). UserHalService(106)는 사용자(12)가 제거되지 않았음을 나타내는 메시지(예를 들어, Result(FAIL, 42))를 CarUserService(104)로 전송할 수 있다(388). CarUserService(104)는 사용자(12)가 제거되지 않았음을 나타내는 메시지(예컨대, listener.onResult(result=OEM_FAIL, 오류=42))를 UI(100)로 제공할 수 있다(390). UI(100)는 사용자(12)가 제거되지 않았다는 표시(단순화를 위해 미도시됨)를 제공할 수 있다. 예를 들어, UI(100)는 사용자(12)가 제거되지 않았다는 메시지를 디스플레이하거나 청각적 표시를 제공할 수 있다.
현대의 차량은 차량이 인간 운전자를 키포브, 얼굴 이미지, 지문 또는 음성 샘플을 통해 컴퓨터에서 사용자와 연관시킬 수 있는 복수의 방식을 갖는다. API(29)는 인증 방법의 체크 및 설정을 제공하도록 구성될 수 있다. 일부 예에서, 그것은 인증을 위해 미리 정의된 값들(예를 들어, 키포브, 얼굴 인증, 블루투스 연결 등)을 제공할 수 있다. 차량 제조업체는 인증을 커스터마이즈할 수 있다. 도 12는 본 개시의 기술에 따른 사용자와 인증 인자의 연관의 예를 나타내는 흐름도이다. 도 12의 예는 인증 인자로서 키포브를 설명하지만, 지문, 얼굴 이미지, 음성 샘플 등과 같은 임의의 인증 인자가 사용될 수 있다. 사용자 인터페이스("UI")(APP UI)(100)는 사용자가 사용하는 키포브와 연관(관련)된 사용자 id를 요청하는 메시지(예를 들어, getUserIdentification((KEY_FOB))를 CarUserManager 애플리케이션(102)으로 전송할 수 있다(392). UI(100)는 도 1에 도시된 예시적인 디스플레이(20)를 나타낼 수 있다. CarUserManager 애플리케이션(102)은 키포브와 연관된 사용자 id를 요청하는 메시지(예컨대, getUserIdentification((KEY_FOB))를 CarUserService(104)로 전송할 수 있다(394). CarUserService(104)는 제1 OS(30)의 예를 나타낼 수 있다. CarUserService(104)는 사용자 id를 제공하는 권한이 인에이블되었는지 여부를 결정할 수 있다(395). 권한이 인에이블된 경우, CarUserService(104)는 키포브와 연관된 사용자 id를 요청하는 메시지(예를 들어, getUserIdentification((KEY_FOB))를 UserHalService(106)로 전송할 수 있다(396). UserHalService(106)는 도 1 및 도 2에 도시된 API(29)의 예를 나타낼 수 있다.
UserHalService(106)는 키포브(398)와 연관된 사용자 id를 요청하는 메시지(예를 들어, USER_IDENTIFICATION_ASSOCIATION(10,(KEY_FOB))를 VehicleHAL (108)로 전송할 수 있다(398). VehicleHAL(108)은 도 1 및 도 2에 도시된 HAL(28)의 예를 나타낼 수 있다. VehicleHAL(108)은 키포브가 사용자 id와 연관되는지 여부를 결정할 수 있다(단순화를 위해 미도시됨).
키포브가가 사용자 id와 연관되어 있는 경우, VehicleHAL(108)은 사용자 id를 UI(100)로 제공할 수 있는 CarUserService (104)(단순화를 위해 미도시됨)에 사용자 id를 제공할 수 있는 UserHalService (106)(단순화를 위해 미도시됨)에게 사용자 id를 제공할 수 있다(단순화를 위해 미도시됨). 사용자 id가 마지막 활성 사용자와 다른 경우, UI(100)는 도 3 내지 도 5에서와 같이, 사용자를 전환하려고 시도할 수 있다(단순화를 위해 미도시됨).
한편, 키포브가 사용자 id와 연관이 없는 경우, VehicleHAL(108)은 키포브가 사용자 id와 연관되지 않음을 나타내는 메시지(예를 들어, USER_IDENTIFICATION_ASSOCIATION(NOT_ASSOCIATED_ANY_USER))를 UserHalService (106)로 제공할 수 있다(400). UserHalService(106)는 키포브가 사용자 id와 연관되지 않음을 나타내는 메시지(예를 들어, (NOT_ASSOCIATED_ANY_USER))를 CarUserService(104)에 전송할 수 있다(402). CarUserService(104)는 키포브가 사용자 id와 연관되지 않음을 나타내는 메시지(예컨대, (NOT_ASSOCIATED_ANY_USER))를 UI(100)에 제공할 수 있다(404). UI(100)는 키포브가 현재 사용자와 연관되도록 요청하는 메시지를 CarUserManager(102)로 전송할 수 있다(406). CarUserManager(102)는 키포브가 현재 사용자(408)와 연관되도록 요청하는 메시지(예를 들어, setUserIdentification((KEY_FOB)))를 CarUserService (104)에 전송할 수 있다(408). CarUserService(104)는 키포브를 현재 사용자와 연관시키는 권한이 인에이블되었는지 여부를 결정할 수 있다(410). 그 권한이 인에이블된 경우, CarUserService(104)는 키포브가 현재 사용자와 연관되도록 요청하는 메시지(예컨대, setUserIdentification((KEY_FOB)))를 UserHalService(106)로 전송할 수 있다(412).
UserHalService(106)는 사용자(10)(현재 사용자의 id)를 키포브와 연관시키도록 VehicleHAL(108)에게 지시하는 메시지(예를 들어, set_USER_IDENTIFICATION_ASSOCIATION(10, KEY_FOB))를 VehicleHAL(108)로 전송할 수 있다(414). VehicleHAL(108)은 현재 사용자를 키포브(단순화를 위해 미도시됨)와 연관시키고, 현재 사용자가 키포브(416)와 이제 연관되어 있음을 나타내는 메시지(예를 들어, USER_IDENTIFICATION_ASSOCIATION(ASSOCIATE_CURRENT_USER)를 UserHalService(106)로 전송할 수 있다(416). UserHalService (106)는 현재 사용자가 이제 키포브와 연관되어 있음을 나타내는 메시지(예를 들어, ASSOCIATE_CURRENT_USER)를 CarUserService(104)로 전송할 수 있다(418). CarUserService(104)는 현재 사용자가 이제 키포브와 연관되어 있음을 나타내는 메시지(예를 들어, ASSOCIATE_CURRENT_USER)를 UI(100)로 다시 전송할 수 있다(420). UI(100)는 현재 사용자에게 이들이 키포브와 연관되어 있다는 표시(예를 들어, 디스플레이된 메시지 또는 청각적 표시)를 제공할 수 있다(단순화를 위해 미도시됨).
도 13은 본 개시의 기술에 따른 사용자 관리 서비스를 제공하는 예의 흐름도이다. 차량의 하나 이상의 프로세서(예를 들어, 프로세서(15))는 제1 운영 체제(예를 들어, 제1 OS(30))를 실행하여 차량에 사용자 관리 서비스를 제공할 수 있다(500). 예를 들어, 프로세서(15)는 시스템 메모리(16)로부터 제1 OS(30)를 로드하고 제1 OS(30)를 실행할 수 있다. 제1 OS(30)는 본 개시에서 논의된 바와 같이 차량에 사용자 관리 서비스를 제공할 수 있다.
제1 운영 체제는 제2 운영 체제가 사용자 관리 동작을 호출하는 제2 운영 체제에 대한 인터페이스를 제시할 수 있다(502). 예를 들어, 제1 OS(30)는 API(29)를제2 OS(31)에 제시할 수 있다. 제2 OS(31)는 API(29)를 사용하여 본 개시에서 설명된 바와 같이 사용자 관리 동작을 호출할 수 있다.
제1 운영 체제는 사용자 관리와 연관된 제1 메시지를 생성할 수 있다(504). 예를 들어, 제1 OS(30)는 사용자 변경 요청, 사용자 생성 메시지, 사용자 삭제 메시지, 초기 사용자 할당 메시지 또는 게스트 사용자 메시지 중 적어도 하나를 포함할 수 있는 사용자 관리와 연관된 제1 메시지를 생성할 수 있다. 일부 예에서, 제1 메시지는 새로운 사용자 프로필(일부 경우에 게스트 사용자 프로필일 수 있음) 또는 초기 사용자 프로필을 더 포함할 수 있다.
인터페이스는 제1 메시지를 제2 운영 체제로 제공할 수 있다(506). 예를 들어, API(29)는 제1 메시지를 제2 OS(31)에 제공할 수 있다. 일부 예에서, API(29)는 제1 메시지를 제2 OS(31)의 HAL(28)에 제공할 수 있다.
인터페이스는 제2 운영 체제로부터 제2 메시지를 수신할 수 있고, 제2 메시지는 제1 운영 체제와 제2 운영 체제사이의 사용자 관리를 동기화시키는 것과 관련된다(508). 예를 들어, API(29)는 제2 OS(31)로부터 제2 메시지를 수신할 수 있다. 일부 예에서, API(29)는 제2 OS(31)의 HAL(28)로부터 제2 메시지를 수신할 수 있다. 일부 예에서, 제2 메시지는 사용자의 변경이 한 번에 허용되는지 여부; 제2 운영 체제에 의해 차량 사용자 관리 시스템에 저장되는 내부 사용자 프로필, 상기 내부 사용자 프로필은 제1 메시지 내의 새로운 사용자 프로필에 기초하고; 사용자가 차량 사용자 관리 시스템에으로부터 삭제되었는지 여부; 또는 현재 사용자가 게스트 사용자인지 여부 중 적어도 하나를 나타낸다.
일부 예에서, 인터페이스는 제2 운영 체제로부터 제3 메시지를 수신할 수 있다. 예를 들어, API(29)는 차량 관리 시스템(예를 들어, 사용자 관리(35))에 저장된 사용자가 없음을 나타낼 수 있는 제3 메시지를 OS(31)(예를 들어, HAL(28))로부터 수신할 수 있다.
도 14a 내지 도 14c는 본 개시의 기술에 따른 사용자 관리 서비스를 제공하는 추가 예의 흐름도이다. 도 14a 내지 도 14c의 임의의 또는 모든 예는 도 13의 예와 함께 사용될 수 있다.
도 14a에서, 제1 운영 체제는 제2 메시지에 기초하여 사용자의 변경이 한 번에 허용되는지 여부를 결정할 수 있다(510). 예를 들어, 제1 OS(30)는 제2 메시지를 판독하여 사용자의 변경이 허용되는 것(예를 들어, 사용자의 변경은 제2 OS(31)에 의해 금지되지 않음)으로 결정할 수 있다. 사용자의 변경이 한 번에 허용된다는 결정에 기초하여, 인터페이스는 제2 운영 체제에 제3 메시지를 제공할 수 있고, 제3 메시지는 차량의 하나 이상의 시스템을 제어한다. 예를 들어, API(29)는 제2 OS(31)(예를 들어, HAL(28))에 제3 메시지를 제공할 수 있다. 제3 메시지는 인체 공학적 시스템, 엔터테인먼트 시스템, 인포테인먼트 시스템, 온도 시스템, 안전 시스템 또는 주행 모드 시스템과 같이 차량의 하나 이상의 시스템을 제어할 수 있다.
도 14b에서, 제1 운영 체제는 제2 메시지에 기초하여 현재 사용자가 게스트 사용자인지 여부를 결정할 수 있다. 예를 들어, 제1 OS(30)는 제2 메시지를 판독하여 현재 사용자가 게스트 사용자임을 결정할 수 있다. 현재 사용자가 게스트 사용자라는 결정에 기초하여, 인터페이스는 제2 운영 체제에 제3 메시지를 제공할 수 있고, 제3 메시지는 제2 운영 체제에 의한 게스트 사용자 프로필의 생성을 제어한다. 예를 들어, API(29)는 제2 OS(31)(예를 들어, HAL(28))에 제3 메시지를 제공할 수 있다. 제3 메시지는 현재 사용자와 연관된 게스트 사용자 프로필의 생성을 제어할 수 있다. 이 게스트 사용자 프로필은 예를 들어 사용자 관리(35)에 저장될 수 있다.
도 14c에서, 제1 운영 체제는 사용자를 인증의 형태와 연관시킬 수 있다(518). 예를 들어, 제1 OS(30)는 키포브, 지문, 얼굴(얼굴 스캔 또는 이미지를 통한) 또는 음성(음성지문을 통한) 중 하나 이상을 사용자와 연관시킬 수 있다. 제1 운영 체제는 인증의 형태에 기초하여 현재 사용자가 마지막 활성 사용자와 다르다고 결정할 수 있다(520). 예를 들어, 제1 OS(30)는 현재 사용자(사용자 관리(35) 또는 차량 시스템(26A-26N) 중 하나일 수 있는 차량 인증 시스템에 저장될 수 있음)에 대한 인증 인자(들)을 조회(룩업)하여 현재 사용자가 마지막 활성 사용자가 아님을 결정할 수 있다. 이 경우, 제1 OS(30)는 사용자를 현재 사용자로 변경하거나, 새로운 사용자를 생성하거나, 게스트 사용자를 생성하는 등을 시도할 수 있다.
도 15는 제1 OS(30) 및 제2 OS(31)의 예시적인 컴포넌트를 도시하는 블록도이다. 제1 OS(30)는 사용자(차량 제조업체와 연관될 수 있음) 및 CarUserManager 애플리케이션(CARUSERMGR)(차량 제조업체와 연관된 소프트웨어 개발 키트일 수 있음)과 연관될 수 있는 설정과 같은 설정 활동(114)을 포함할 수 있다. 제1 OS(30)는 또한 CarUserService(104), UserHalService(106), IActivityManager(110) 및 IUserManager(112)를 포함할 수 있다. 제2 OS(31)는 사용자 관리를 위해 제2 OS(31)에 의해 이용될 수 있는 VehicleHAL(108) 및 OEM 특정 컴포넌트(122)를 포함할 수 있다. VehicleHAL(108)은 아래에서 더 논의되는 HAL 특성(120)을 포함할 수 있다.
일부 예에서, 제1 OS(30)는 제1 OS(30)가 HAL(28)에게 어떤 유형의 사용자(예를 들어, 초기 사용자, 게스트 사용자, 일반 사용자)가 사용되어야 하는지 전달하도록 요청하기 시작할 때 API(29)를 통해 메시지를 HAL(28)로 전송할 수 있다. 이 메시지는 제1 부팅(예를 들어, 처음으로 자동차가 시동된 경우), 콜드(cold) 부팅(예를 들어, 제1 부팅 후 일반 부팅) 또는 RAM 일시 중단(예를 들어, 절전모드 해제)과 같은 다른 유형의 시작시 전송될 수 있다. HAL(28)은 제1 OS(30)에 의해 사용될 사용자 유형으로 API(29)에 응답할 수 있다. 일부 예에서, 제1 부팅, 콜드 부팅 또는 RAM으로부터의 일시 중단 동안, 제1 OS(30)는 HAL(28)을 호출할 수 있다. HAL(28)은 기존 사용자로의 전환, 사용자 생성 또는 이 둘의 혼합을 생성할 수 있다.
일부 예에서, 콜백 이벤트가 인에이블될 수 있다. 예를 들어, 제1 OS(30)는 사용자가 잠금 해제되거나 전환될 때 제1 OS(30)상에서 실행될 수 있는 애플리케이션(차량 제조업체에 의해 제공될 수 있음)에 통지를 전송할 수 있다.
제1 OS(30)가 부팅될 때, 제1 OS(30)는 CarServiceHelperService를 사용하여 어느 사용자로 전환할지를 결정할 수 있다. 예를 들어, 제1 부팅시, OS(30)는 초기 사용자(예를 들어, 사용자(10))를 생성할 수 있다. 다른 부팅 또는 RAM 일시 중단에서, OS(30)는 사용자를 마지막 활성 사용자로 전환할 수 있다. 다른 예에서, OS(30)는 차량을 잠금 해제한 FOB와 연관되거나 다른 인증 인자와 연관된 사용자로 사용자를 전환할 수 있다.
본 명세서에서 논의된 예는 다양한 워크 플로우를 개시하는 UI(100)에 초점을 두고 있지만, 일부 예에서, HAL(28)은 워크 플로우를 개시할 수 있다. 예를 들어, 차량 얼굴 인식 시스템(예를 들어, 차량 시스템(26) 중 하나)이 최종 사용자와 다른 사용자를 검출할 때, HAL(28)은 메시지를 API(29)에 전송하여 사용자 전환을 개시할 수 있다.
일부 예에서, OS(30)는 다른 방식으로 HAL(28)과 상호 작용할 수 있다. 예를 들어, 사용자 전환, 생성 및 제거는 다음과 같이 인터페이스로 추상화될 수 있다.
package android . os . user;
/** @hide */
public interface UserCreator {
UserInfo createUser (String name , String userType , int flags);
boolean removeUser (int userId );
}
/** @hide */
public interface UserSwitcher {
boolean switchUser (int targetUserId);
}
UserManagerService 및 ActivityManagerService는 선택적으로 다음 인터페이스를 사용할 수 있다.
public class ActivityManagerService ... {
private UserSwitcher mUserSwitcher = null ;
@Override
public boolean switchUser ( final int targetUserId ) {
Boolean ok = true;
if ( mUserSwitcher != null ) {
Ok = mUserSwitcher .CanI swith switchToUser ( targetUserId );
return switchUserDirectly ( targetUserId );
}
}
private boolean switchUserDirectly ( int targetUserId ) {
return mUserController . switchUser ( targetUserId );
}
}
본 개시의 기술을 제1 OS(30)의 기존 사용자 관리 API와 통합하기 위해 기본 내부 서비스에 기술들이 추가될 수 있다. 예를 들어, CarServiceHelperServer는 다음과 같이 변경될 수 있다.
public class CarServiceHelperService implements UserSwitcher , UserCreator {
@Override
public boolean switchToUser ( int targetUserId ) {
Listener halListener = ??
CountdownLatch latch = new CountDownLatch ( 1 );
userHal . switchUser ( targetUserId , () -> { latch . countDown () });
latch . await (); // let's not worry about timeout / error handling for now...
return mAmInternal . switchUser ( targetUserId );
}
}
일부 예에서, UserManager는 사용자가 전환될 수 있는지를 체크하기 위해 호출될 수 있는 API를 제공할 수 있다.
일부 예에서, HAL(28) 메시지는 현재 사용자 상태에 관한 정보(예를 들어, 현재 사용자 id, 모든 사용자의 목록 등)를 포함한다. 일부 예에서, HAL(28)은 현재 사용자 상태에 관한 정보를 이용하여 HAL(28)의 사용자 상태를 제1 OS(30)의 사용자 상태와 동기시킬 수 있다. 일부 예에서, 제1 OS(30) 콜백은 현재 사용자 상태에 관한 정보도 포함할 수 있다.
일부 예에서, CarUserService(104)는 언제든지 하나의 동작만 실행되도록 보장할 수 있다. 예를 들어, 이전 요청이 완료되기 전에 사용자 전환 요청이 시도되면, CarUserService(104)는 그 새로운 사용자 전환 요청에 실패할 수 있다.
일부 예에서, API(29) 메시지에 대한 HAL(28) 응답은 동기적일 수 있다. 그러한 경우, 본 개시의 기술은 구현하기가 더 간단할 수 있다. 예를 들어, 애플리케이션으로부터의 호출자는 단방향 바인더 트랜잭션(binder transaction)을 발행할 수 있으므로, UserHalService(106)는 HAL(28)이 응답할 때까지 차단할 수 있다. 그러나, HAL(28)이 응답하지 않으면 이로 인해 많은 스레드가 차단될 수 있다.
다른 예에서, API(29)에 대한 HAL(28) 응답은 비동기적일 수 있다. 이러한 예에서, 상태 머신은 요청을 응답에 매핑하는데 사용될 수 있으며 UserHalService는 더 가벼울 수 있다.
VehicleHAL(108)의 예시적인 구현은 다음과 같다.
/**
* 초기화 동안 사용될 초기 Android 사용자를 정의한다.
* 이 속성은 초기화할 때 Android 시스템에 의해 호출되며 이를 통해 HAL은 시작해야하는 Android 사용자를 정의할 수 있다.
* 이 요청은 (InitialUserInfoRequest에 의해 정의된) VehiclePropValue를 설정하여 이루어지고, HAL은 (InitialUserInfoResponse에 의해 정의된) 속성 변경 이벤트로 응답해야 한다.
* 만약 HAL이 (Android 시스템에 의해 정의된) 일정 시간 후에 응답하지 않으면, Android 시스템은 HAL이 액션 InitialUserInfoResponseAction:DEFAULT의 응답을 리턴한 것처럼 진행한다.
* 예를 들어, 제1 부팅에서, 요청은 다음과 같다.
*
* int32[0]: 42 // request id(arbitrary number set by Android system)
* int32[1]: 1 // InitialUserInfoRequestType::FIRST_BOOT
* int32[2]: 0 // id of current user(usersInfo.currentUser.userId)
* int32[3]: 1 // flag of current user(usersInfo.currentUser.flags = SYSTEM)
* int32[4]: 1 // number of existing users(usersInfo.numberUsers);
* int32[5]: 0 // user #0(usersInfo.existingUsers[0].userId)
* int32[6]: 1 // flags of user #0(usersInfo.existingUsers[0].flags)
* 그리고 HAL이 "관리(Admin)"라고 불리는 관리 사용자를 작성하여 응답하려는 경우, 그 응답은 다음과 같다:
* int32[0]: 42 // must match the request id from the request
* int32[1]: 2 // action = InitialUserInfoResponseAction::CREATE
* int32[2]: -1 // userToSwitchOrCreate.userId(not used as user will be created)
* int32[3]: 8 // userToSwitchOrCreate.flags = ADMIN
* string: "Admin" // userNameToCreate
*
* NOTE: 만약 HAL이 사용자 관리를 지원하지 않는 경우 이 속성을 정의해서는 안되는데, 이는 다른 사용자 관련 속성을 디스에이블시킨다(예를 들어, Android 시스템은 이를 발행하지 않으며 HAL 계층의 사용자 관련 요청은 Android 시스템에 의해 무시된다). 그러나, 만약 사용자 관리를 지원하는 경우, 모든 사용자 관련 속성 (INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER 및 USER_IDENTIFICATION_ASSOCIATION)을 지원해야 한다.
*
* @change_mode VehiclePropertyChangeMode:ON_CHANGE
* @access VehiclePropertyAccess:READ_WRITE
*/
INITIAL_USER_INFO =(
0x0F07
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL),
/**
* 포어그라운드 Android 사용자를 전환하기 위한 요청을 정의한다.
* 이 속성은 주로 Android 시스템에서 사용되어 현재 포어 그라운드 Android 사용자가 전환하고 있음을 HAL에 알리지만, HAL에서 사용되어 사용자를 전환하도록 Android 시스템에 요청하는데 사용될 수도 있다.
* Android가 요청을 하는 경우 VehiclePropValue를 설정하고 HAL은 속성 변경 이벤트에 응답해야 한다. HAL이 요청을 하는 경우 속성 변경 이벤트를 통해서도 요청해야 한다(주된 차이점은 요청 id는 전자의 경우 양수이고 후자의 경우 음수라는 것이며; SwitchUserMessageType도 다르다는 것이다.
* 두 요청의 포멧은 SwitchUserRequest에 의해 정의되고 응답 포멧(필요한 경우)은 SwitchUserResponse에 의해 정의된다. HAL(또는 Android 시스템)의 진행 방식은 아래 정의된 (SwitchUserMessageType 파라미터에 의해 정되된) 메시지 유형에 따라 다릅니다.
*
* 1.레거시_안드로이드_전환(LEGACY_ANDROID_SWITCH)
* ----------------
* HAL과 통합되지 않은 방식(예를 들어, adb shell am switch-user를 통해)으로 변경 요청이 이루어진 경우 Android 사용자가 변경하려고 한다는 것을 나타내기 위해 Android 시스템에 의해 호출된다.
* HAL은 이 요청을 일단 받으면 내부 사용자를 전환할 수 있지만, Android 시스템에 회신할 필요는 없다. 내부 사용자가 어떤 이유로 변경될 수 없는 경우에는, SWITCH_USER(type = ANDROID_POST_SWITCH) 호출이 복구될 때까지(예를 들어, SWITCH_USER(type = VEHICLE_REQUEST)를 발행하여 이전 사용자로 다시 전환할 수 있을 때까지) 기다려야 하지만, (다시 전환하면 최종 사용자에게 혼란을 줄 수 있으므로) 이상적으로는 절대로 실패해서는 안된다.
* 예를 들어, 시스템에 사용자(0, 10, 11)가 있고 0에서 11로 전환하는 경우 (특별한 플래그가 없는 경우) 요청은 다음과 같다.
*
* int32[0]: 42 // request id
* int32[1]: 1 // SwitchUserMessageType::LEGACY_ANDROID_SWITCH
* int32[2]: 11 // target user id
* int32[3]: 0 // target user flags(none)
* int32[4]: 10 // current user
* int32[5]: 0 // current user flags(none)
* int32[6]: 3 // number of users
* int32[7]: 0 // user #0(Android user id 0)
* int32[8]: 0 // flags of user #0(none)
* int32[9]: 10 // user #1(Android user id 10)
* int32[10]: 0 // flags of user #1(none)
* int32[11]: 11 // user #2(Android user id 11)
* int32[12]: 0 // flags of user #2(none)
*
* 2. 안드로이드_스위치(ANDROID_SWITCH_
* ----------------
* Android 사용자가 변경되려고 함을 나타내기 위해 Android 시스템에 의해 호출되지만, Android는 진행하기 전에 (일부 시간까지) HAL의 응답을 기다린다.
* HAL은 이 요청을 받으면 내부 사용자를 전환한 다음 내부 사용자가 전환되었는지 여부를 나타내는 SWITCH_USER(type=VEHICLE_RESPONSE)를 사용하여 Android에 다시 응답해야 한다(SwitchUserStatus 이넘(enum)을 통해).
* 예를 들어, Android에 사용자(0, 10, 11)가 있고 10에서 11로 전환하는 경우(특별한 플래그가 없는 경우) 요청은 다음과 같다.
*
* int32[0]: 42 // request id
* int32[1]: 2 // SwitchUserMessageType::ANDROID_SWITCH
* int32[2]: 11 // target user id
* int32[3]: 0 // target user flags(none)
* int32[4]: 10 // current user
* int32[5]: 0 // current user flags(none)
* int32[6]: 3 // number of users
* int32[7]: 0 // 1st user(user 0)
* int32[8]: 0 // 1st user flags(none)
* int32[9]: 10 // 2nd user(user 10)
* int32[10]: 0 // 2nd user flags(none)
* int32[11]: 11 // 3rd user(user 11)
* int32[12]: 0 // 3rd user flags(none)
*
* 만약 요청이 성공하면 HAL은 다음을 사용하여 속성을 업데이트해야 한다.
*
* int32[0]: 42 // request id
* int32[1]: 3 // messageType = SwitchUserMessageType::VEHICLE_RESPONSE
* int32[2]: 1 // status = SwitchUserStatus::SUCCESS
*
* 그러나, 실패하면 응답은 다음과 같다.
* int32[0]: 42 // request id
* int32[1]: 3 // messageType = SwitchUserMessageType::VEHICLE_RESPONSE
* int32[2]: 2 // status = SwitchUserStatus::FAILURE
* string: "108-D'OH!" // OEM-spefic error message
*
* 3. 차량_응답(VEHICLE_RESPONSE)
* ------------------
* ANDROID_SWITCH 유형의 요청이 진행 또는 중단되어야하는지 여부를 표시하기 위해 HAL에 의해 호출된다. 자세한 정보는 위의 ANDROID_SWITCH 섹션을 참조한다.
*
* 4. 차량_요청(VEHICLE_REQUEST)
* ------------------
* 현재 포어 그라운드 Android 사용자가 전환되도록 요청하기 위해 HAL에 의해 호출된다.
* 이는 Android가 한 명의 사용자로 시작했지만 차량이 그 운전자를 다른 사용자로 식별한 경우에 유용하다. 예를 들어, 사용자 A는 사용자 B의 키포브(key fob)를 사용하여 차량의 잠금을 해제했다.
* INITIAL_USER_INFO 요청은 사용자 B를 리턴했지만, 얼굴 인식 서브 서브 시스템은 사용자를 A로 식별했다.
* HAL은 (네거티브 요청 id를 전달하는) 속성 변경 이벤트로 이 요청을 하고, Android 시스템은 동일한 요청 id를 가진 ANDROID_POST_SWITCH 호출을 issuye에 의해 응답한다.
* 예를 들어, 현재 포어 그라운드 Android 사용자가 10이고 HAL이 11로 전환하도록 요청한 경우 그 요청은 다음과 같다.
*
* int32[0]: -108 // request id
* int32[1]: 4 // messageType = SwitchUserMessageType::VEHICLE_REQUEST
* int32[2]: 11 // Android user id
*
* 만약 그 요청이 성공하고 Android에 3명의 사용자(0, 10, 11)가 있는 경우, 응답은 다음과 같다.
* int32[0]: -108 // request id
* int32[1]: 5 // messageType = SwitchUserMessageType::ANDROID_SWITCH
* int32[2]: 11 // target user id
* int32[3]: 11 // target user id flags(none)
* int32[4]: 11 // current user
* int32[5]: 0 // current user flags(none)
* int32[6]: 3 // number of users
* int32[7]: 0 // 1st user(user 0)
* int32[8]: 0 // 1st user flags(none)
* int32[9]: 10 // 2nd user(user 10)
* int32[10]: 4 // 2nd user flags(none)
* int32[11]: 11 // 3rd user(user 11)
* int32[12]: 3 // 3rd user flags(none)
*
* 현재 사용자 id와 타겟 사용자 id는 동일한데-만약 요청이 실패하면 달라질 수 있다(즉, 타겟 사용자는 11이지만 현재 사용자는 여전히 10이다).
*
* 5.안드로이드_포스트_스위치(ANDROID_POST_SWITCH)
* ---------------------
* 사용자 전환 요청이 이루어진 후 Android 시스템에 의해 호출된다.
* 이 속성은 모든 유형의 전환 요청(예를 들어, LEGACY_ANDROID_SWITCH, ANDROID_SWITCH 또는 VEHICLE_REQUEST) 후에 호출되며 요청의 성공 또는 실패 여부를 결정하는데 사용될 수 있다.
*
* 1. 요청이 성공하면, Android 사용자가 부팅 잠금 상태일 때 호출되고, 응답에서 현재 사용자 id와 타겟 사용자 id의 값이 다르다. 이는 Android 앱에서 Intent.ACTION_LOCKED_BOOT_COMPLETED를 수신하는 것과 동일하다.
* 2. 요청이 실패하면 바로 호출되며, 응답에서 사용자 id와 타겟 사용자 id의 값이 동일하다.
* HAL은 일단 이 요청을 수신하면 내부 상태를 업데이트할 수 있지만 Android 시스템에 회신할 필요는 없다.
* 요청(Request): INITIAL_USER_INFO에 의해 정의된 첫 번째 N 값(여기서 인덱스 1의 요청 특정 값은 SwitchUserMessageType :: ANDROID_POST_SWITCH 임), 타겟 사용자 id(즉, 전환 요청된 Android 사용자 id) 및 해당 플래그(UserFlags에 의해 정의됨)에 대한 2개의 추가 값.
* 응답(Response): 없음(none).
예 : 위의 차량_요청 섹션을 참조한다.
*
* @change_mode VehiclePropertyChangeMode:ON_CHANGE
* @access VehiclePropertyAccess:READ_WRITE
*/
SWITCH_USER =(
0x0F08
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
/**
* Android 사용자가 생성된 후 Android 시스템에 의해 호출된다.
* HAL은 이 속성을 사용하여 동등한(equivalent) 사용자를 생성할 수 있다.
* 이것은 비동기 요청이다. Android는 VehiclePropValue를 설정함으로써 이 요청을 하고, HAL은 이 요청의 성공 또는 실패 여부를 나타내는 속성 변경으로 응답해야 한다.
* 만약 요청이 실패하면 Android 시스템은 사용자를 제거할 것이다.
* 이 요청의 포멧은 CreateUserRequest에 의해 정의되고 그 응답의 포멧은 CreateUserResponse에 의해 정의된다.
* 예를 들어, 시스템에 2명의 사용자(0 및 10)가 있고 세 번째 사용자(일시적인 게스트)가 생성된, 그 요청은 다음과 같다.
* int32[0]: 42 // request id
* int32[1]: 11 // Android id of the created user
* int32[2]: 3 // Android flags(ephemeral guest) of the created user
* int32[3]: 10 // current user
* int32[4]: 0 // current user flags(none)
* int32[5]: 3 // number of users
* int32[6]: 0 // 1st user(user 0)
* int32[7]: 0 // 1st user flags(none)
* int32[8]: 10 // 2nd user(user 10)
* int32[9]: 0 // 2nd user flags(none)
* int32[19]: 11 // 3rd user(user 11)
* int32[11]: 3 // 3rd user flags(ephemeral guest)
* string: "ElGuesto" // name of the new user
*
* 그런 다음 만약 요청이 성공하면, HAL은 다음을 반환한다.
*
* int32[0]: 42 // request id
* int32[1]: 1 // CreateUserStatus::SUCCESS
*
* 그러나 실패하면:
*
* int32[0]: 42 // request id
* int32[1]: 2 // CreateUserStatus::FAILURE
* string: "D'OH!" // 이 의미는 블랙박스이다-이것은 // 적절한 조치를 취할 수 있는 (설정 UI와 같은) 호출자에게 전달된다,
*
* @change_mode VehiclePropertyChangeMode:ON_CHANGE
* @access VehiclePropertyAccess:READ_WRITE
*/
CREATE_USER =(
0x0F09
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL),
/**
* Android 사용자가 제거된 후 Android 시스템에 의해 호출된다.
* HAL은 이 속성을 사용하여 그의 동등한 사용자를 제거할 수 있다.
* 이것은 기록 전용 호출이다-Android 시스템은 HAL의 응답을 기대하지 않는다. 따라서, 이 요청은 실패하지 않아야 한다- 만약 동등한 HAL 사용자를 제거할 수 없는 경우, HAL은 이를 비활성으로 마킹하거나 다른 방법으로 복구해야 한다.
* 동등한 HAL 사용자를 제거 할 수없는 경우 HAL은이를 비활성으로 표시하거나 다른 방법으로 복구해야 한다.
* 요청은 RemoveUserRequest에 의해 정의된 내용으로 VehiclePropValue를 설정함으로써 이루어진다.
* 예를 들어, 시스템에 3명의 사용자(0, 10 및 11)가 있고 사용자 11이 제거 된 경우, 요청은 다음과 같다.
* int32[0]: 42 // request id
* int32[1]: 11 //(Android user id of the removed user)
* int32[2]: 0 //(Android user flags of the removed user)
* int32[3]: 10 // current user
* int32[4]: 0 // current user flags(none)
* int32[5]: 2 // number of users
* int32[6]: 0 // 1st user(user 0)
* int32[7]: 0 // 1st user flags(none)
* int32[8]: 10 // 2nd user(user 10)
* int32[9]: 0 // 2nd user flags(none)
*
* @change_mode VehiclePropertyChangeMode:STATIC
* @access VehiclePropertyAccess:WRITE
*/
REMOVE_USER =(
0x0F0A
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL),
/**
* 현재 사용자를 (예를 들어, 키포브와 같은) 차량별 식별 메커니즘과 연관시키는데(또는 연관을 조회하는데) 사용되는 속성이다.
* 연관을 조회하기 위해 Android 시스템은 UserIdentificationGetRequest에 의해 정의된 대로, 연관의 유형을 포함하는 VehiclePropValue를 전달하여 이 속성을 가져온다.
* HAL은 VehiclePropValue를 UserIdentificationResponse로 업데이트하여 즉시 반환해야 한다. 시스템을 부팅하는 동안 사용자 식별이 이미 수행되어 있어야 하며, VHAL 구현은 get 호출로부터 새로운 연관을 시작하는 대신 이미 식별된 연관(예를 들어, 자동차 잠금을 해제하는데 사용되는 키포브)만 반환해야 한다.
* 유형을 연관시키기 위해 Android 시스템은 UserIdentificationSetRequest에 정의된 대로, 설정되는 연관의 유형 및 값을 포함하는 VehiclePropValue를 전달하여 속성을 설정한다. 그런 다음 HAL은 요청 후 유형들의 현재 상태를 나타내는 속성 변경 이벤트(이의 VehiclePropValue는 UserIdentificationResponse에 의해 정의됨)를 사용한다.
* 예를 들어, 현재 사용자(10)가 자동차를 잠금 해제한 포브(FOB) 및 OEM에 의해 제공된 커스텀 메커니즘과 연관되어 있는지 조회하려면, 요청은 다음과 같다.
* int32[0]: 10(Android user id)
* int32[1]: 0(Android user flags)
* int32[2]: 2(number of types queried)
* int32[3]: 1(1st type queried, UserIdentificationAssociationType::KEY_FOB)
* int32[4]: 101(2nd type queried, UserIdentificationAssociationType::CUSTOM_1)
*
* 만약 사용자가 FOB와 연관되어 있지만 커스텀 메커니즘과 연관되지 않은 경우, 그 응답은 다음과 같다.
* int32[9]: 2(number of associations in the response)
* int32[1]: 1(1st type: UserIdentificationAssociationType::KEY_FOB)
* int32[2]: 2(1st value:
UserIdentificationAssociationValue::ASSOCIATED_CURRENT_USER)
* int32[3]: 101(2st type: UserIdentificationAssociationType::CUSTOM_1)
* int32[4]: 4(2nd value:
UserIdentificationAssociationValue::NOT_ASSOCIATED_ANY_USER)
*
* 그런 다음 사용자를 커스텀 메커니즘과 연관시키기 위해, 설정 요청(set request)이 이루어진다.
*
* int32[0]: 10(Android user id)
* int32[0]: 0(Android user flags)
* int32[1]: 1(number of associations being set)
* int32[2]: 101(1st type: UserIdentificationAssociationType::CUSTOM_1)
* int32[3]: 1(1st value: UserIdentificationAssociationSETValue::ASSOCIATE_CURRENT_USER)
*
* 만약 요청이 성공하면 응답은 다음과 같다.
*
* int32[0]: 2(number of associations in the response)
* int32[1]: 101(1st type: UserIdentificationAssociationType::CUSTOM_1)
* int32[2]: 1(1st value: UserIdentificationAssociationValue::ASSOCIATED_CURRENT_USER)
*
* 설정 요청은 연관(associations)을 추가하지만 기존 연관은 제거하지 않음에 유의한다. 위의 예에서, 종료(end) 상태는 2개의 연관(FOB 및 CUSTOM_1)이다. 만약 사용자를 FOB가 아닌 CUSTOM_1에만 연관시키려는 경우, 요청은 다음과 같아야 한다.
*
* int32[0]: 10(Android user id)
* int32[1]: 2(number of types set)
* int32[2]: 1(1st type: UserIdentificationAssociationType::KEY_FOB)
* int32[3]: 2(1st value: UserIdentificationAssociationValue::DISASSOCIATE_CURRENT_USER)
* int32[3]: 101(2nd type: UserIdentificationAssociationType::CUSTOM_1)
* int32[5]: 1(2nd value: UserIdentificationAssociationValue::ASSOCIATE_CURRENT_USER)
*
* @change_mode VehiclePropertyChangeMode:ON_CHANGE
* @access VehiclePropertyAccess:READ_WRITE
*/
USER_IDENTIFICATION_ASSOCIATION =(
0x0F0B
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL),
};
/**
* 특정 Android 사용자에 대한 정보.
*/
struct UserInfo {
UserId userId;
UserFlags flags;
};
/**
* Android 사용자의 Id.
*
* 유효한 id의 경우 0보다 크거나, 사용하지 않을 때는 -10000 (Android.UserHandle.USER_NULL과 동일함)이어야 한다.
*/
typedef int32_t UserId;
/**
* Android 사용자의 특성을 정의하는데 사용되는 플래그
*/
enum UserFlags : int32_t {
/**
* No flags.
*/
NONE = 0x0,
/**
* 시스템 사용자.
* 자동차상에서, 해당 사용자는 항상 실행 중이지만 절대로 포어 그라운드에서는 실행되지 않는다(부팅 또는 예외적인 상황 제외).
*/
SYSTEM = 0x01,
/**
* 게스트 사용자는 제한이 있다.
*/
GUEST = 0x02,
/**
* 임시 사용자는 비-영구 상태이다.
*/
EPHEMERAL = 0x04,
/**
* 관리(Admin) 사용자에게는 다른 사용자를 생성하기 위한 권한과 같은 추가 특권이 있다.
*/
ADMIN = 0x08,
};
/**
* 모든 Android 사용자에 대한 정보.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HALdp 의해 제공되는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되는 다른 구조의 일부이다.
*/
struct UsersInfo {
/** The current foreground user. */
UserInfo currentUser;
/** Number of existing users(includes the current user). */
int32_t numberUsers;
/** List of existing users(includes the current user). */
vec < UserInfo > existingUsers;
};
/**
* 사용자 관리와 관련된 요청의 Id.
* 이 id는 Android 시스템에서 HAL이 전송한 응답을 매핑하는데 사용될 수 있으며 그 반대도 마찬가지이다.
* Android에 의해 발신된 요청의 경우 값은 양수(> 0)이고, HAL에 의해 발신된 요청의 경우 음수(<0)이어야 한다.
*/
typedef int32_t UserRequestId;
/**
* Android 시스템에 의해 이루어진 INITIAL_USER_INFO 요청의 포멧을 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에 의해 제공되는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct InitialUserInfoRequest {
/**
* HAL 응답을 요청에 매핑하는데 사용되는 임의의 ID.
*/
UserRequestId requestId;
/**
* 요청의 유형.
*/
InitialUserInfoRequestType requestType;
/**
* Android 시스템의 현재 상태에 대한 정보.
*/
*/UsersInfo usersInfo;
};
/**
* INITIAL_USER_INFO 요청시기를 정의한다.
*/
enum InitialUserInfoRequestType : int32_t {
/** At the first time Android was booted(or after a factory reset). */ FIRST_BOOT = 1,
/** At the first time Android was booted after the system was updated. */
FIRST_BOOT_AFTER_OTA = 2,
/** When Android was booted "from scratch". */
COLD_BOOT = 3,
/** When Android was resumed after the system was suspended to memory. */
RESUME = 4,
};
/**
* INITIAL_USER_INFO 요청에 대한 HAL 응답의 포멧을 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct InitialUserInfoResponse {
/**
* 응답되는 요청의 Id.
*/
UserRequestId requestId;
/**
* Android 시스템에서 수행해야 할 액션.
*/
InitialUserInfoResponseAction action;
/**
* 전환하거나 생성되어야 하는 사용자에 대한 정보.
*/
UserInfo userToSwitchOrCreate;
/**
* 생성되어야 하는 사용자의 이름.
*/
string userNameToCreate;
};
/**
* INITIAL_USER_INFO 요청에서 Android 시스템이 수행할 액션을 정의한다.
*/
enum InitialUserInfoResponseAction : int32_t {
/**
* 안드로이드 시스템이 무엇을 할지 결정하게 한다.
* 예를 들어, 처음 부팅할 때 새로운 사용자를 생성하고 나중에 마지막 활성 사용자로 전환할 수 있다.
*/
DEFAULT = 0,
/**
* 기존 Android 사용자로 전환한다.
*/
SWITCH = 1,
/**
* 새로운 Android 사용자를 생성한다(그것으로 전환한다).
*/
CREATE = 2,
};
/**
* SWITCH_USER 속성의 포멧을 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct SwitchUserRequest {
/*
* 응답을 요청에 매핑하는데 사용되는 임의의(Arbitrary) id.
*/
UserRequestId requestId;
/**
* 메시지 타입.
*/
SwitchUserMessageType messageType;
/**
* 전환중인 Android 사용자에 대한 정보.
* HAL에 의해 요청이 이루어질 때 사용자 id(플래그는 아님)만 설정되어야 한다.
*/
UserInfo targetUser;
/**
* Android 시스템의 현재 상태에 대한 정보.
* HAL에 의해 요청이 이루어질때 설정되지 않아야 한다
*/
UsersInfo usersInfo;
};
/**
* SWITCH_USER 호출이 발생한 이유를 정의한다.
* 각 상수의 의미는 해당 속성에 설명되어 있다.
*/
enum SwitchUserMessageType : int32_t {
LEGACY_ANDROID_SWITCH = 1,
ANDROID_SWITCH = 2,
VEHICLE_RESPONSE = 3,
VEHICLE_REQUEST = 4,
ANDROID_POST_SWITCH = 5,
};
/**
* SwitchUserRequest의 결과를 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct SwitchUserResponse {
/**
* 응답되는 요청의 Id.
*/
UserRequestId requestId;
/**
* 메시지 타입.
*/
SwitchUserMessageType messageType;
/**
* 요청의 상태.
*/
SwitchUserStatus status;
/**
* HAL-관련(specific) 오류 메시지.
* 이 인수는 선택 사항이며, 정의된 경우 "있는 그대로(as-is)" 호출자에게 전달된다. 이것은 최종 사용자에게 커스텀 오류 메시지를 표시하는데 사용될 수 있다.
*/
string errorMessage;
};
/**
* SwitchUserRequest에 대한 응답 상태.
*/
enum SwitchUserStatus : int32_t {
/** 요청이 성공했으며 HAL 사용자는 전환되었다. */
SUCCESS = 1,
/** 요청이 실패했으며 HAL 사용자는 동일하게 유지되었다. */
FAILURE = 2,
};
/**
* CREATE_USER 속성의 포멧을 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct CreateUserRequest {
/**
* 응답을 요청에 매핑하는데 사용되는 임의의 id.
*/
UserRequestId requestId;
/**
* 생성된 Android 사용자에 대한 기본 정보.
*/
UserInfo newUserInfo;
/**
* 새로운 Android 사용자의 이름.
*/
string newUserName;
/**
* Android 시스템의 현재 상태에 대한 정보.
*/
UsersInfo usersInfo;
};
/**
* CreateUserRequest의 결과를 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct CreateUserResponse {
/**
* 응답되는 요청의 Id.
*/
UserRequestId requestId;
/**
* 요청의 상태.
*/
CreateUserStatus status;
/**
* HAL-관련 오류 메시지.
* 이 인수는 선택 사항이며, 정의된 경우 "있는 그대로" 호출자에게 전달된다. 최종 사용자에게 커스텀 오류 메시지를 표시하는데 사용될 수 있다.
*/
string errorMessage;
};
/**
* CreateUserRequest에 대한 응답의 상태.
*/
enum CreateUserStatus : int32_t {
/**
* 요청이 성공함(예를 들어, HAL은 새로운 내부 사용자를 생성하거나 Android 사용자를 기존 내부 사용자와 연관시킴).
*/
SUCCESS = 1,
/**
* 요청이 실패함(Android는 Android 사용자를 제거한다).
*/
FAILURE = 2,
};
/**
* REMOVE_USER 속성의 포멧을 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct RemoveUserRequest {
/**
* 응답을 요청에 매핑하는데 사용되는 임의의 ID.
*/
UserRequestId requestId;
/**
* 제거된 Android 사용자에 대한 정보.
*/
UserInfo removedUserInfo;
/**
* Android 시스템의 현재 상태에 대한 정보.
*/
UsersInfo usersInfo;
};
/**
* Android 사용자를 식별하는데 사용되는 메커니즘의 유형.
*
* 보다 상세한 내용과 예는 USER_IDENTIFICATION_ASSOCIATION을 참조하십시오.
*/
enum UserIdentificationAssociationType : int32_t {
/** Key used to unlock the car. */
KEY_FOB = 1,
/** Custom mechanism defined by the OEM. */
CUSTOM_1 = 101,
/** Custom mechanism defined by the OEM. */
CUSTOM_2 = 102,
/** Custom mechanism defined by the OEM. */
CUSTOM_3 = 103,
/** Custom mechanism defined by the OEM. */
CUSTOM_4 = 104,
};
/**
* UserIdentificationAssociation Type이 Android 사용자와 연관되는지 여부.
*/
enum UserIdentificationAssociationValue : int32_t {
/**
* 연결 상태를 확인할 수 없을 때 사용됨.
*
* 예를 들어 set() 요청에서, 주어진 유형을 설정하는데 실패했음을 나타낸다.
*/
UNKNOWN = 1,
/**
* 식별 유형은 현재 포어 그라운드 Android 사용자와 연관된다.
*/
ASSOCIATED_CURRENT_USER = 2,
/**
* 식별 유형은 다른 Android 사용자와 연관되어 있다.
*/
ASSOCIATED_ANOTHER_USER = 3,
/**
* 식별 유형은 Android 사용자와 관련이 없다.
*/
NOT_ASSOCIATED_ANY_USER = 4,
};
/**
* Android 사용자로 UserIdentificationAssociationType을 설정하는데 사용된다.
*/
enum UserIdentificationAssociationSetValue : int32_t {
/**
* 식별 유형을 현재 포어 그라운드 Android 사용자와 연관시킨다.
*/
ASSOCIATE_CURRENT_USER = 1,
/**
* 현재 포어 그라운드 Android 사용자로부터 식별 유형을 분리한다.
*/
DISASSOCIATE_CURRENT_USER = 2,
/**
* 모든 Android 사용자로부터 식별 유형을 분리(Disassociate)한다.
*/
DISASSOCIATE_ALL_USERS = 3,
};
/**
* USER_IDENTIFICATION_ASSOCIATION에 대한 get () 호출 포멧을 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct UserIdentificationGetRequest {
/**
* 현재 포어 그라운드 Android 사용자에 대한 정보.
*/
UserInfo userInfo;
/**
* 조회중인 연관의 수.
*/
int32_t numberAssociationTypes;
/**
* 조회중인 연관의 유형.
*/
vec < UserIdentificationAssociationType > associationTypes;
};
/**
* USER_IDENTIFICATION_ASSOCIATION에 대한 set () 호출의 포멧을 정의한다.
*
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct UserIdentificationSetRequest {
/**
* 현재 포어 그라운드 Android 사용자에 대한 정보.
*/
UserInfo userInfo;
/**
* 설정중인 연관의 수.
*/
int32_t numberAssociations;
/**
* 설정중인 연관.
*/
vec < UserIdentificationAssociationSetValue > associations;
};
/**
* get() 및 set() 모두에 대해 USER_IDENTIFICATION_ASSOCIATION의 결과를 정의한다.
* NOTE: 이 구조는 HAL 속성에서 직접 사용되지 않으며, 디폴트 Vehicle HAL 구현에서 제공하는 라이브러리를 통해 VehiclePropValue.RawValue로 변환되어야 한다.
*/
struct UserIdentificationResponse {
/**
* 반환되는 연관의 수.
*/
int32_t numberAssociation;
/**
* 사용자와 연관된 값들.
*/
vec < UserIdentificationAssociation > associations;
/**
* HAL-관련 오류 메시지.
* 이 인수는 선택 사항으로, 정의된 경우 "있는 그대로" 호출자에게 전달된다. 이는 최종 사용자에게 커스텀 오류 메시지를 표시하는데 사용될 수 있다.
*/
string errorMessage;
};
/**
* 사용자/id 연관 유형을 가져올(get) 때 사용되는 헬퍼 구조.
*/
struct UserIdentificationAssociation {
UserIdentificationAssociationType type;
UserIdentificationAssociationValue value;
};
/**
* 사용자/id 연관 유형을 설정(set)할 때 사용되는 헬퍼 구조.
*/
struct UserIdentificationSetAssociation {
UserIdentificationAssociationType type;
UserIdentificationAssociationSetValue value;
};
VehicleHAL 108의 다른 구현 예는 다음과 같다.
/**
int0: current user id
int1: target user id
int2: number of existing users
int3+: list of existing users
response:
int0: SwitchUserResponseType
int1: custom error code
@change_mode VehiclePropertyChangeMode:ON_CHANGE
@access VehiclePropertyAccess:READ
*/
SWITCH_USER_REQUEST =(
0x0F08
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
enum SwitchUserResponseType : int32_t {
SUCCESS = 0,
FAILURE = 1,
};
/**
int0: SwitchRequestStatus
int1: previous user id
int2: current user id
int3: number of existing users
int4+: list of existing users
response: not used
@change_mode VehiclePropertyChangeMode:ON_CHANGE
@access VehiclePropertyAccess:READ
*/
SWITCH_USER_POST_REQUEST =(
0x0F09
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
enum SwitchRequestStatus : int32_t {
SUCCESS = 0,
FAILURE = 1,
};
/**
request:
int0: user id
int1: user flags
string: userType,name
response:
int0: CreateUserResponseType
int1: custom error code
@change_mode VehiclePropertyChangeMode:ON_CHANGE
@access VehiclePropertyAccess:READ
*/
CREATE_USER_REQUEST =(
0x0F0a
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
enum CreateUserResponseType : int32_t {
SUCCESS = 0,
FAILURE = 1,
};
/**
request:
int0: user id
response:
int0: RemoveUserResponseType
@change_mode VehiclePropertyChangeMode:ON_CHANGE
@access VehiclePropertyAccess:READ
*/
REMOVE_USER_REQUEST =(
0x0F0b
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
enum RemoveUserResponseType : int32_t {
SUCCESS = 0,
FAILURE = 1,
};
/**
int0: InitialUserInfoResponseType
int1: number of existing users
int2+: list of existing users
response:
int0: behavior
int1: user id(or UserId:NONE when not used)
string: userType,name(or empty when not used)
@change_mode VehiclePropertyChangeMode:STATIC
@access VehiclePropertyAccess:READ
*/
INITIAL_USER_INFO_REQUEST =(
0x0F07
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
enum InitialUserInfoRequestType : int32_t {
FIRST_BOOT = 0,
COLD_BOOT = 1,
SUSPEND_FROM_RAM = 2,
};
enum InitialUserInfoResponseType : int32_t {
DEFAULT = 0,
SWITCH = 1,
CREATE = 2,
SWITCH_OR_CREATE = 3,
};
enum UserId : int32_t {
NONE = - 1,
};
/**
request:
int0: user id
string: custom message
response:
string: custom message
@change_mode VehiclePropertyChangeMode:ON_CHANGE
@access VehiclePropertyAccess:READ
*/
SEND_USER_MESSAGE =(
0x0F0c
| VehiclePropertyGroup : SYSTEM
| VehiclePropertyType : MIXED
| VehicleArea : GLOBAL ),
CarUserManager(102)의 예시적인 구현은 다음과 같다:
package android. car. user;
public final class CarUserManager {
void switchUser(@NonNull UserSwitchListener listener, int targetUserId );
void createUser(@NonNull UserCreationListener listener, @NonNull String userType, @Nullable String name, int flags);
void removeUser(@NonNull UserRemovalListener listener, int userId);
void sendMessageToHal(@NonNull HalMessageListener listener, @NonNull String message);
void registerListener(@NonNull UserLifecycleListener listener);
void unregisterListener(@NonNull UserLifecycleListener listener);
void isUserIdentificationSet(@NonNull listener, @NonNull int [] types)
void setCurrentUserAssociated(@NonNull List <UserIdenticationType> types)
public static final int USER_ASSOCIATION_KEY_FOB = 1;
public static final int USER_ASSOCIATION_FACE_AUTHENTICATION = 2;
public static final int USER_ASSOCIATION_PHONE_AUTHENTICATION = 3;
public static final int USER_ASSOCIATION_BLUETOOTH_ASSOCIATION = 4;
// Custom forms defined by OEM4
public static final int USER_ASSOCIATION_CUSTOM_1 = 11;
public static final int USER_ASSOCIATION_CUSTOM_2 = 12;
public static final int USER_ASSOCIATION_CUSTOM_3 = 13;
public static final int USER_ASSOCIATION_CUSTOM_4 = 14;
public static final int USER_ASSOCIATION_CUSTOM_5 = 15;
/** @hide */
public final class UserSwitchResult {
enum Status { SUCCESS , CAR_FAILURE, ANDROID_FAILURE }
@NonNull Status getStatus();
int getCustomErrorCode();
}
public interface UserSwitchListener {
void onResult(@NonNull UserSwitchResult result);
}
public final class UserCreationResult {
enum Status { SUCCESS , CAR_FAILURE, ANDROID_FAILURE }
@NonNull Status getStatus();
int getUserId();
int getCustomErrorCode();
}
public interface UserCreationListener {
void onResult(@NonNull UserCreationResult result);
}
public final class UserRemovalResult {
enum Status { SUCCESS , CAR_FAILURE, ANDROID_FAILURE }
@NonNull Status getStatus();
int getCustomErrorCode();
}
public interface UserRemovalListener {
void onResult(@NonNull UserRemovalResult result);
}
public final class UserLifecycleEvent {
Enum EventType { CREATED, SWITCHING, UNLOCKED, SWITCHED, STOPPED, REMOVED }
int getCurrentUserId();
int getTargetUserId();
}
public interface UserLifecycleListener {
void onEvent(@NonNull UserLifecycleEvent);
}
} // CarUserManager
일부 예에서, 프레임 워크 구성 특성(속성)에 의해 정의된 특정 사용자 관련 설정은 HAL(28) 내에 있을 수 있다. 그런 경우, 속성값이 HAL(28)에 즉시(오버레이된 리소스를 파싱하기 전에)이용 가능하다는 장점은 (예를 들어, 시스템 메모리(16)의 현재 저장 용량에 기초하여 최대 사용자 수를 정의하는) 값들을 동적으로 변경할 수 있다는 것이다.
이러한 경우, 초기 설정은 UserController에 전달될 수 있다. 일부 예에서 초기 설정은 ActivityManagerService.retrieveSettings()상의 UserController로 전달되는데, 이는 CarServiceHelperService가 인스턴스화되기 전에 ActivityManagerService.systemReady()로부터 호출된다. 상기 초기 설정을 UserController에 전달하는 예시 기술은 ActivityManagerService.systemReady()에 의해 사용되는 goingCallback이 설정을 반환하도록 하는 것이다. 구현 예는 다음과 같다.
void ActitivyManagerService . systemReady(Callable <InitialSettings> goingCallback) {
// initialize stuff
if( goingCallback != null ) {
InitialSettings initalSettings = goingCallback . call();
If( initialSettings != null ) {
updateSettings( initialSettings );
}
}
void SystemServer . startOtherServices() {
mActivityManagerService . systemReady(() -> {
InitialSettings initialSettings = null ;
if( mPackageManager . hasSystemFeature( PackageManager . FEATURE_AUTOMOTIVE )) {
Supplier < InitialSettings > supplier =
startService( CAR_SERVICE_HELPER_SERVICE_CLASS );
initialSettings = supplier . get();
}
return initalSettings ;
}
그런 다음 CarServiceHelperService는 VehicleHAL(108)로부터 값들을 판독함으로써 그 인터페이스를 구현할 수 있다.
또 다른 예시적인 기술은 ActivityManagerService가 초기 값을 설정한 다음, ActivityManagerInternal상에서 새로운 방법을 호출함으로써 CarManagerHelper가 시작될 때 CarManagerHelper가 초기 값을 대체하도록 설정하는 것이다.
interface ActivityManagerInternal {
public abstract void setUserControllerSettings( BootSettings userBootSettings );
}
/** @hide */
public final class android . os . user . BootSettings {
public final int maxRunningUsers ;
public final boolean userSwitchUiEnabled ;
public final boolean delayUserDataLocking ;
}
예로서, 이러한 컴퓨터 판독 가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 저장 장치, 자기 디스크 저장 장치, 또는 명령 또는 데이터 구조의 형태로 원하는 프로그램 코드를 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 저장 매체를 포함할 수 있으나 이에 한정되지 않는다. 또한, 모든 연결은 컴퓨터 판독 가능 매체로 적절히 지칭된다. 예를 들어, 동축 케이블, 광섬유 케이블, 트위스트 페어, DSL(Digital Subscriber Line) 또는 적외선, 라디오 및 마이크로웨이브와 같은 무선 기술을 사용하여 웹 사이트, 서버 또는 기타 원격 소스로부터 명령들이 전송되는 경우 동축 케이블, 광섬유 케이블, 트위스트 페어(twisted pair), DSL, 또는 적외선, 라디오 및 마이크로웨이브와 같은 무선 기술은 매체의 정의에 포함된다. 그러나, 컴퓨터 판독 가능 저장 매체(medium) 및 매체(media) 및 데이터 저장 매체는 연결, 반송파, 신호 또는 다른 일시적인 매체를 포함하지 않고, 비-일시적인 유형(tangible)의 저장 매체로 지향된다는 것을 이해해야 한다. 본 명세서에서 사용되는 디스크(Disk) 및 디스크(disc)는 컴팩트 디스크(CD), 레이저 디스크, 광 디스크, 디지털 다목적 디스크(DVD), 플로피 디스크(disk) 및 블루레이 디스크를 포함하며, 여기서 디스크(disk)는 일반적으로 자기 적으로 데이터를 재생하는 반면, 디스크(disc)는 레이저로 광학적으로 데이터를 재생한다. 상기의 조합은 또한 컴퓨터 판독 가능 매체의 범위 내에 포함되어야 한다.
명령들은 하나 이상의 디지털 신호 프로세서(DSP), 범용 마이크로 프로세서, 주문형 집적 회로(ASIC), 필드 프로그래머블 로직 어레이(FPGA)와 같은 하나 이상의 프로세서, 또는 기타 동가 집적 또는 이산 논리 회로에 의해 실행될 수 있다. 따라서, 본 명세서에서 사용되는 용어 "프로세서"는 전술한 구조 중 어느 하나 또는 본 명세서에 설명된 기술의 구현에 적합한 임의의 다른 구조를 지칭할 수 있다. 또한, 일부 양태에서, 본 명세서에 설명된 기능은 전용 하드웨어 및/또는 소프트웨어 모듈 내에 제공될 수 있다. 또한, 기술들은 하나 이상의 회로 또는 논리 요소에서 완전히 구현될 수 있다.
본 개시의 기술들은 무선 핸드셋, 집적 회로(IC) 또는 IC 세트(예를 들어, 칩 세트)를 포함하여 다양한 디바이스 또는 장치에서 구현될 수 있다. 개시된 기술들을 수행하도록 구성된 디바이스들의 기능적 측면을 강조하기 위해 다양한 컴포넌트, 모듈 또는 유닛이 본 개시에서 설명되지만, 반드시 상이한 하드웨어 유닛들에 의한 실현될 필요는 없다. 오히려, 전술한 바와 같이, 다양한 유닛은 하드웨어 유닛으로 조합되거나 적절한 소프트웨어 및/또는 펌웨어와 함께 전술한 바와 같은 하나 이상의 프로세서를 포함하는 상호 운용 가능한 하드웨어 유닛의 컬렉션에 의해 제공될 수 있다.
본 개시는 많은 예를 포함한다. 이러한 예는 다음을 포함한다.
예 1. 방법은 차량의 하나 이상의 프로세서에 의해, 차량에 사용자 관리 서비스를 제공하도록 제1 운영 체제를 실행하는 단계와; 하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 제2 운영 체제가 사용자 관리 동작을 호출하는 인터페이스를 제2 운영 체제에 제시하는 단계와; 하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 사용자 관리와 관련된 제1 메시지를 생성하는 단계와; 인터페이스에 의해, 제1 메시지를 제2 운영 체제로 제공하는 단계와; 그리고 인터페이스에 의해, 제2 운영 체제로부터 상기 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련된 제2 메시지를 수신하는 단계를 포함한다.
예 2. 예 1에 있어서, 제 1 메시지는 사용자 변경 요청을 포함한다.
예 3. 예 2에 있어서, 하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 제2 메시지에 기초하여 사용자 변경이 한 번에 허용되는지 여부를 결정하는 단계와; 그리고 사용자 변경이 한번에 허용된다는 결정에 기초하여, 인터페이스에 의해, 제2 운영 체제에 제3 메시지를 제공하는 단계를 더 포함하고, 상기 제3 메시지는 차량의 하나 이상의 시스템을 제어한다.
예 4. 예 2에 있어서, 제3 메시지는 차량의 하나 이상의 시스템의 동작 상태에 대한 현재 사용자의 선호도를 더 포함한다.
예 5. 예 1에 있어서, 제1 메시지는 사용자 생성 메시지를 포함한다.
예 6. 예 5에 있어서, 제1 메시지는 새로운 사용자 프로필 메시지를 더 포함한다.
예 7. 예 6에 있어서, 제2 메시지는 제2 운영 체제에 의해 차량 사용자 관리 시스템에 저장되는 내부 사용자 프로필을 나타내고, 내부 사용자 프로필은 새로운 사용자 프로필에 기초한다.
예 8. 예 1에 있어서, 제1 메시지는 사용자 삭제 메시지를 포함한다.
예 9. 예 8에 있어서, 제2 메시지는 차량 사용자 관리 시스템으로부터 사용자가 삭제되었음을 나타낸다.
예 10. 예 8에 있어서, 제2 메시지는 하나 이상의 프로세서에 의해 실행되는 제2 운영 체제에 의해, 사용자가 현재 사용자가 아니라는 결정을 추가로 나타낸다.
예 11. 예 1에 있어서, 제1 메시지는 초기 사용자 할당 메시지를 포함한다.
예 12. 예 11에 있어서, 제1 메시지는 초기 사용자 프로필을 더 포함한다.
예 13. 예 12에 있어서, 인터페이스에 의해, 하나 이상의 프로세서에 의해 실행되는 제2 운영 체제로부터 제3 메시지를 수신하는 단계를 더 포함하고, 상기 제3 메시지는 차량 사용자 관리 시스템에 저장된 사용자가 없음을 나타내고, 상기 제2 메시지는 하나 이상의 프로세서에 의해 실행되는 제2 운영 체제에 의해, 초기 사용자 프로필에 기초하여 저장되는 내부 사용자 프로필을 나타낸다.
예 14. 예 1에 있어서, 제1 메시지는 게스트 사용자 메시지를 포함한다.
예 15. 예 14에 있어서, 하나 이상의 프로세서에서 실행되는 제1 운영 체제에 의해, 제2 메시지에 기초하여 현재 사용자가 게스트 사용자인지 여부를 결정하는 단계와; 그리고 현재 사용자가 게스트 사용자라는 결정에 기초하여, 인터페이스에 의해, 하나 이상의 프로세서에서 실행되는 제2 운영 체제에 제3 메시지를 제공하는 단계를 더 포함하고, 상기 제3 메시지는 차량 사용자 관리 시스템에서 하나 이상의 프로세서에 의해 실행되는 제2 운영 체제에 의한 게스트 사용자 프로필의 생성을 제어한다.
예 16. 예 1 내지 예 15의 임의의 조합에 있어서, 하나 이상의 프로세서에서 실행되는 제1 운영 체제에 의해, 사용자를 인증 형태(form)와 연관시키는 단계를 더 포함한다.
예 17. 예 16에 있어서, 인증 형태는 키포브(key fob), 지문, 얼굴 또는 음성 중 하나 이상을 포함한다.
예 18. 예 1 내지 예 17의 임의의 조합에 있어서, 하나 이상의 프로세서에서 실행되는 제1 운영 체제에 의해, 현재 사용자가 마지막 활성 사용자와 다르다는 것을 결정하는 단계를 더 포함한다.
예 19. 예 18에 있어서, 현재 사용자가 마지막 활성 사용자와 다르다는 것을 결정하는 단계는 현재 키포브, 지문, 얼굴 또는 음성이 마지막 활성 사용자와 연관되지 않은 것을 결정하는 단계를 포함한다.
예 20. 예 1 내지 예 19의 임의의 조합에 있어서, 차량의 하나 이상의 시스템은 인체 공학적 시스템, 엔터테인먼트 시스템, 인포테인먼트 시스템, 기온 시스템, 안전 시스템 또는 주행 모드 시스템을 포함한다.
예 21. 예 1 내지 예 20의 임의의 조합에 있어서, 인터페이스는 제2 운영 체제의 차량 하드웨어 추상화 계층으로 메시지를 제공하고 그 차량 하드웨어 추상화 계층으로부터 메시지를 수신한다.
예 22. 예 1 내지 예 21의 임의의 조합에 있어서, 하나 이상의 프로세서는 제2 운영 체제를 실행한다.
예 22. 차량과 상호 작용하도록 구성된 디바이스로서, 디바이스는 사용자 관리 데이터를 저장하도록 구성된 메모리와; 그리고 메모리에 통신 가능하게 결합되고 그리고 사용자 관리 동작을 호출하기 위해 제2 운영 체제에 인터페이스를 제시하는 제1 운영 체제를 실행하도록 구성된 하나 이상의 프로세서를 포함하고, 상기 제1 운영 체제는 사용자 관리와 관련된 제1 메시지를 생성하도록 구성되고, 상기 인터페이스는 제1 메시지를 제2 운영 체제에 제공하도록 구성되고, 상기 인터페이스는 제2 운영 체제로부터 제2 메시지를 수신하도록 더 구성되며, 상기 제2 메시지 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련되고, 그리고 상기 제1 운영 체제는 제1 메시지에 기초하여 차량에 사용자 관리 서비스를 제공한다.
예 24. 예 23에 있어서, 제 1 메시지는 사용자 변경 요청을 포함한다.
예 25. 예 24에 있어서, 제1 운영 체제는 제2 메시지에 기초하여 사용자 변경이 한 번에 허용되는지 여부를 결정하도록 추가로 구성되고, 상기 인터페이스는 제2 운영 체제에 제3 메시지를 제공하도록 추가로 구성되고, 상기 제3 메시지는 사용자 변경이 한번에 허용된다는 결정에 기초하여 차량의 하나 이상의 시스템을 제어한다.
예 26. 예 25에 있어서, 제3 메시지는 차량의 하나 이상의 시스템의 동작 상태에 대한 현재 사용자의 선호도를 더 포함한다.
예 27. 예 23에 있어서, 제1 메시지는 사용자 생성 메시지를 포함한다.
예 28. 예 27에 있어서, 제1 메시지는 새로운 사용자 프로필 메시지를 더 포함한다.
예 29. 예 28에 있어서, 제2 메시지는 제2 운영 체제에 의해 차량 사용자 관리 시스템에 저장되는 내부 사용자 프로필을 나타내고, 내부 사용자 프로필은 새로운 사용자 프로필에 기초한다.
예 30. 예 23에 있어서, 제1 메시지는 사용자 삭제 메시지를 포함한다.
예 31. 예 30에 있어서, 제2 메시지는 차량 사용자 관리 시스템으로부터 사용자가 삭제되었음을 나타낸다.
예 32. 예 31에 있어서, 제2 메시지는 하나 이상의 프로세서에 의해 실행되는 제2 운영 체제에 의해, 사용자가 현재 사용자가 아니라는 결정을 추가로 나타낸다.
예 33. 예 23에 있어서, 제1 메시지는 초기 사용자 할당 메시지를 포함한다.
예 34. 예 33에 있어서, 제1 메시지는 초기 사용자 프로필을 더 포함한다.
예 35. 예 34에 있어서, 인터페이스는 제2 운영 체제로부터 제3 메시지를 수신하도록 더 구성되고, 제3 메시지는 차량 사용자 관리 시스템에 저장된 사용자가 없음을 나타내고, 제2 메시지는 차량 사용자 관리 시스템에 저장되는 내부 사용자 프로필을 나타낸다.
예 36. 예 23에 있어서, 제1 메시지는 게스트 사용자 메시지를 포함한다.
예 37. 예 36에 있어서, 제1 운영 체제는 제2 메시지에 기초하여 현재 사용자가 게스트 사용자인지 여부를 결정하도록 더 구성되고, 인터페이스는 현재 사용자가 게스트 사용자라는 결정에 기초하여 제2 운영 체제에 제3 메시지를 제공하도록 더 구성된다.
예 38. 예 23 내지 예 37의 임의의 조합에 있어서, 제1 운영 체제는 사용자를 인증 형태와 연관시키도록 더 구성된다.
예 39. 예 38에 있어서, 인증 형태는 키포브, 지문, 얼굴 또는 음성 중 하나 이상을 포함한다.
예 40. 예 23 내지 예 39의 임의의 조합에 있어서, 제1 운영 체제는 현재 사용자가 마지막 활성 사용자와 다르다는 것을 결정하도록 더 구성된다.
예 41. 예 40에 있어서, 제1 운영 체제는 현재 키포브, 지문, 얼굴 또는 음성이 마지막 활성 사용자와 연관되지 않음을 결정함으로써 현재 사용자가 마지막 활성 사용자와 다르다고 결정한다.
예 42. 예 23 내지 예 41의 임의의 조합에 있어서, 차량의 하나 이상의 시스템은 인체 공학적 시스템, 엔터테인먼트 시스템, 인포테인먼트 시스템, 기온 시스템, 안전 시스템 또는 주행 모드 시스템을 포함한다.
예 43. 예 23 내지 예 42의 임의의 조합에 있어서, 인터페이스는 제 2 운영 체제의 차량 하드웨어 추상화 계층에 메시지를 제공하고 차량 하드웨어 추상화 계층으로부터 메시지를 수신하도록 구성된다.
예 44. 예 23 내지 예 43의 임의의 조합에 있어서, 하나 이상의 프로세서는 제 운영 체제를 실행하도록 더 구성된다.
예 45. 명령들이 저장된 비-일시적 컴퓨터 판독 가능 저장 매체로서, 명령들은 실행될 때, 차량 헤드 유닛의 하나 이상의 프로세서로 하여금: 차량에 사용자 관리 서비스를 제공하기 위해 제1 운영 체제를 실행하고; 제2 운영 체제가 사용자 관리 동작을 호출하는 제1 운영 체제의 인터페이스를 제2 운영 체제에 제시하고; 사용자 관리와 관련된 제1 메시지를 생성하고; 인터페이스에 의해, 제1 메시지를 제2 운영 체제에 제공하고; 그리고 인터페이스에 의해, 제2 운영 체제로부터 상기 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련된 제2 메시지를 수신하게 한다.
예 46. 예 45에 있어서, 제1 메시지는 사용자 변경 요청을 포함한다.
예 47. 예 46에 있어서, 명령들은 추가로 실행될 때 하나 이상의 프로세서로 하여금: 제2 메시지에 기초하여 사용자 변경이 한 번에 허용되는지 여부를 결정하고; 그리고 사용자 변경이 한 번에 허용된다는 결정에 기초하여, 인터페이스에 의해, 제2 운영 체제에 제3 메시지를 제공하도록 하고, 제3 메시지는 차량의 하나 이상의 시스템을 제어한다.
예 48. 예 47에 있어서, 제3 메시지는 차량의 하나 이상의 시스템의 동작 상태에 대한 현재 사용자의 선호도를 더 포함한다.
예 49. 예 45에 있어서, 제1 메시지는 사용자 생성 메시지를 포함한다.
예 50. 예 49에 있어서, 제1 메시지는 새로운 사용자 프로필 메시지를 더 포함한다.
예 51. 예 50에 있어서, 제2 메시지는 제2 운영 체제에 의해 차량 사용자 관리 시스템에 저장되는 내부 사용자 프로필을 나타내고, 내부 사용자 프로필은 새 사용자 프로필에 기초한다.
예 52. 예 45에 있어서, 제1 메시지는 사용자 삭제 메시지를 포함한다.
예 53. 예 52에 있어서, 제2 메시지는 사용자가 차량 사용자 관리 시스템으로부터 삭제되었음을 나타낸다.
예 54. 예 53에 있어서, 제2 메시지는 하나 이상의 프로세서에 의해 실행되는 제2 운영 체제에 의해, 사용자가 현재 사용자가 아니라는 결정을 추가로 나타낸다.
예 55. 예 45에 있어서, 제1 메시지는 초기 사용자 할당 메시지를 포함한다.
예 56. 예 55에 있어서, 제1 메시지는 초기 사용자 프로필을 더 포함한다.
예 57. 예 56에 있어서, 명령들은 추가로 실행될 때 하나 이상의 프로세서로 하여금: 인터페이스에 의해, 제2 운영 체제로부터 차량 사용자 관리 시스템에 저장된 사용자가 없음을 나타내는 제3 메시지를 수신하게 하고, 제2 메시지는 제2 운영 체제에 의해, 초기 사용자 프로필에 기초하여 저장되는 내부 사용자 프로필을 나타낸다.
예 58. 예 45에 있어서, 제1 메시지는 게스트 사용자 메시지를 포함한다.
예 59. 예 58에 있어서, 명령들은 추가로 실행될 때 하나 이상의 프로세서로 하여금: 제1 운영 체제에 의해, 제2 메시지에 기초하여 현재 사용자가 게스트 사용자인지 여부를 결정하고; 그리고 인터페이스에 의해, 차량 사용자 관리 시스템에서 제2 운영 체제에 의한 게스트 사용자 프로필의 생성을 제어하는 제3 메시지를 제2 운영 체제에 제공하게 한다.
예 60. 예 45 내지 예 59의 임의의 조합에 있어서, 명령들은 추가로 실행될 때 하나 이상의 프로세서로 하여금 제1 운영 체제에 의해, 사용자와 인증 형태를 연관시키도록 한다.
예 61. 예 60에 있어서, 인증 형태는 키포브, 지문, 얼굴 또는 음성 중 하나 이상을 포함한다.
예 62. 예 45 내지 예 61의 임의의 조합에 있어서, 명령들은 추가로 실행될 때 하나 이상의 프로세서로 하여금 하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 현재 사용자가 마지막 활성 사용자와 다른지 결정하게 한다.
예 63. 예 62에 있어서, 제1 운영 체제는 현재 키포브, 지문, 얼굴 또는 음성이 마지막 활성 사용자와 연관되지 않은 것을 결정함으로써 현재 사용자가 마지막 사용자와 다르다고 결정한다.
예 64. 예 45 내지 예 63의 임의의 조합에 있어서, 차량의 하나 이상의 시스템은 인체 공학적 시스템, 인포테인먼트 시스템, 기온 시스템, 안전 시스템 또는 주행 모드 시스템을 포함한다.
예 65. 예 45 내지 예 64의 임의의 조합에 있어서, 인터페이스는 제2 운영 체제의 차량 하드웨어 추상화 계층에 메시지를 제공하고 차량 하드웨어 추상화 계층으로부터 메시지를 수신하도록 구성된다.
예 66. 예 45 내지 예 65의 임의의 조합에 있어서, 명령들은 추가로 실행될 때 하나 이상의 프로세서로 하여금 제2 운영 체제를 실행하게 한다.
다양한 실시예들이 설명되었다. 이들 및 다른 실시 양태는 하기의 청구 범위의 범주 내에 있다.
Claims (20)
- 방법으로서,
차량의 하나 이상의 프로세서에 의해, 차량에 사용자 관리 서비스를 제공하도록 제1 운영 체제를 실행하는 단계;
하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 제2 운영 체제가 사용자 관리 동작을 호출하는 인터페이스를 제2 운영 체제에 제시하는 단계;
하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 사용자 관리와 관련된 제1 메시지를 생성하는 단계;
인터페이스에 의해, 제1 메시지를 제2 운영 체제로 제공하는 단계; 및
인터페이스에 의해, 제2 운영 체제로부터 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련된 제2 메시지를 수신하는 단계를 포함하는 것을 특징으로 하는 방법. - 제1항에 있어서,
제1 메시지는,
사용자 변경 요청, 사용자 생성 메시지, 사용자 삭제 메시지, 초기 사용자 할당 메시지 또는 게스트 사용자 메시지 중 적어도 하나를 포함하는 것을 특징으로 하는 방법. - 제2항에 있어서,
제1 메시지는,
사용자 생성 메시지 또는 초기 사용자 할당 메시지 중 적어도 하나를 포함하고, 제1 메시지는 새로운 사용자 프로필 또는 초기 사용자 프로필 중 적어도 하나를 더 포함하는 것을 특징으로 하는 방법. - 제1항에 있어서,
제2 메시지는,
사용자 변경이 한 번에 허용되는지 여부와;
제2 운영 체제에 의해 차량 사용자 관리 시스템에 저장된 내부 사용자 프로필과, 그 내부 사용자 프로필은 제1 메시지 내의 새로운 사용자 프로필에 기초하고;
사용자가 차량 사용자 관리 시스템에서 삭제되었는지 여부; 또는
현재 사용자가 게스트 사용자인지 여부 중 적어도 하나를 나타내는 것을 특징으로 하는 방법. - 제4항에 있어서,
하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 제2 메시지에 기초하여 사용자 변경이 한 번에 허용되는지 여부를 결정하는 단계; 및
사용자 변경이 한번에 허용된다는 결정에 기초하여, 인터페이스에 의해, 제2 운영 체제에 차량의 하나 이상의 시스템을 제어하는 제3 메시지를 제공하는 단계를 더 포함하는 것을 특징으로 하는 방법. - 제5항에 있어서,
차량의 하나 이상의 시스템은,
인체 공학적 시스템, 엔터테인먼트 시스템, 인포테인먼트 시스템, 기온 (climate) 시스템, 안전 시스템 또는 주행 모드 시스템 중 적어도 하나를 포함하는 것을 특징으로 하는 방법. - 제4항에 있어서,
하나 이상의 프로세서에서 실행되는 제1 운영 체제에 의해, 제2 메시지에 기초하여 현재 사용자가 게스트 사용자인지 여부를 결정하는 단계; 및
현재 사용자가 게스트 사용자라는 결정에 기초하여, 인터페이스에 의해, 제2 운영 체제에 그 제2 운영 체제에 의한 게스트 사용자 프로필의 생성을 제어하는 제3 메시지를 제공하는 단계를 더 포함하는 것을 특징으로 하는 방법. - 제1항에 있어서,
인터페이스에 의해, 제2 운영 체제로부터 차량 사용자 관리 시스템에 저장된 사용자가 없음을 나타내는 제3 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법. - 제1항에 있어서,
하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 사용자를 인증 형태(form)와 연관시키는 단계; 및
하나 이상의 프로세서에 의해 실행되는 제1 운영 체제에 의해, 인증 형태에 기초하여 현재 사용자가 마지막 활성 사용자와 다른지 결정하는 단계를 더 포함하고,
인증 형태는 키포브(key fob), 지문, 얼굴 또는 음성 중 하나 이상을 포함하는 것을 특징으로 하는 방법. - 제1항에 있어서,
인터페이스는,
제2 운영 체제의 차량 하드웨어 추상화 계층으로 메시지를 제공하고 차량 하드웨어 추상화 계층으로부터 메시지를 수신하는 것인 것을 특징으로 하는 방법. - 차량과 상호 작용하도록 구성된 디바이스로서, 그 디바이스는,
사용자 관리 데이터를 저장하도록 구성된 메모리; 및
메모리에 통신 가능하게 결합되고 사용자 관리 동작을 호출하기 위해 제2 운영 체제에 인터페이스를 제시하는 제1 운영 체제를 실행하도록 구성된 하나 이상의 프로세서를 포함하고,
제1 운영 체제는 사용자 관리와 관련된 제1 메시지를 생성하도록 구성되고, 인터페이스는 제1 메시지를 제2 운영 체제에 제공하도록 구성되고, 인터페이스는 제2 운영 체제로부터 제2 메시지를 수신하도록 더 구성되며, 제2 메시지는 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련되고, 그리고
제1 운영 체제는 제1 메시지에 기초하여 차량에 사용자 관리 서비스를 제공하는 것을 특징으로 하는 디바이스. - 제11항에 있어서,
제1 메시지는,
사용자 변경 요청, 사용자 생성 메시지, 사용자 삭제 메시지, 초기 사용자 할당 메시지 또는 게스트 사용자 메시지 중 적어도 하나를 포함하는 것을 특징으로 하는 디바이스. - 제12항에 있어서,
제1 메시지는,
사용자 생성 메시지 또는 초기 사용자 할당 메시지 중 적어도 하나를 포함하고, 제1 메시지는 새로운 사용자 프로필 또는 초기 사용자 프로필 중 적어도 하나를 더 포함하는 것을 특징으로 하는 디바이스. - 제11항에 있어서,
제2 메시지는
사용자 변경이 한 번에 허용되는지 여부와;
제2 운영 체제에 의해 차량 사용자 관리 시스템에 저장된 내부 사용자 프로필과, 그 내부 사용자 프로필은 제1 메시지 내의 새로운 사용자 프로필에 기초하고;
사용자가 차량 사용자 관리 시스템에서 삭제되었는지 여부; 또는
현재 사용자가 게스트 사용자인지 여부 중 적어도 하나를 나타내는 것을 특징으로 하는 디바이스. - 제14항에 있어서,
제1 운영 체제는,
제2 메시지에 기초하여 사용자 변경이 한 번에 허용되는지 여부를 결정하도록 추가로 구성되고, 인터페이스는 제2 운영 체제에 사용자 변경이 한번에 허용된다는 결정에 기초하여 차량의 하나 이상의 시스템을 제어하는 제3 메시지를 제공하도록 더 구성되는 것을 특징으로 하는 디바이스. - 제15항에 있어서,
차량의 하나 이상의 시스템은,
인체 공학적 시스템, 엔터테인먼트 시스템, 인포테인먼트 시스템, 기온 시스템, 안전 시스템 또는 주행 모드 시스템 중 적어도 하나를 포함하는 것을 특징으로 하는 디바이스. - 제14항에 있어서,
제1 운영 체제는,
제2 메시지에 기초하여 현재 사용자가 게스트 사용자인지 여부를 결정하도록 추가로 구성되고, 인터페이스는 제2 운영 체제에 현재 사용자가 게스트 사용자라는 결정에 기초하여 제2 운영 체제에 의한 게스트 사용자 프로필의 생성을 제어하는 제3 메시지를 제공하도록 더 구성되는 것을 특징으로 하는 디바이스. - 제11항에 있어서,
인터페이스는,
제2 운영 체제로부터 차량 사용자 관리 시스템에 저장된 사용자가 없음을 나타내는 제3 메시지를 수신하도록 더 구성되는 것을 특징으로 하는 디바이스. - 제11항에 있어서,
제1 운영 체제는,
사용자를 인증 형태와 연관시키고;
인증 형태에 기초하여 현재 사용자가 마지막 활성 사용자와 다른지 결정하도록 더 구성되고,
인증 형태는 키포브, 지문, 얼굴 또는 음성 중 하나 이상을 포함하는 것을 특징으로 하는 디바이스. - 명령들이 저장된 비-일시적 컴퓨터 판독 가능 저장 매체로서, 명령들은 실행될 때, 차량 헤드 유닛의 하나 이상의 프로세서로 하여금:
차량에 사용자 관리 서비스를 제공하기 위해 제1 운영 체제를 실행하고;
제2 운영 체제가 사용자 관리 동작을 호출하는 제1 운영 체제의 인터페이스를 제2 운영 체제에 제시하고;
사용자 관리와 관련된 제1 메시지를 생성하고;
인터페이스에 의해, 제1 메시지를 제2 운영 체제에 제공하고; 그리고
인터페이스에 의해, 제2 운영 체제로부터 제1 운영 체제와 제2 운영 체제사이의 사용자 관리 동기화와 관련된 제2 메시지를 수신하게 하는 것을 특징으로 하는 비-일시적 컴퓨터 판독 가능 저장 매체.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US202062990910P | 2020-03-17 | 2020-03-17 | |
| US62/990,910 | 2020-03-17 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20210116162A true KR20210116162A (ko) | 2021-09-27 |
| KR102371527B1 KR102371527B1 (ko) | 2022-03-07 |
Family
ID=71119917
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020200079252A KR102371527B1 (ko) | 2020-03-17 | 2020-06-29 | 차량용 운영 체제와 차량 제조업체 사용자 관리 시스템의 통합 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US11403155B2 (ko) |
| EP (1) | EP3882765A1 (ko) |
| JP (1) | JP7051939B2 (ko) |
| KR (1) | KR102371527B1 (ko) |
| CN (1) | CN111880951B (ko) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2015528673A (ja) * | 2012-08-31 | 2015-09-28 | トウェドル グループ | 自動車ヘッドユニットを伴った通信およびサービスを提供するためのシステム、方法、および物品 |
| US20170080949A1 (en) * | 2015-09-21 | 2017-03-23 | Honda Motor Co., Ltd. | System and method for applying vehicle settings in a vehicle |
| EP3361711A1 (en) * | 2017-02-08 | 2018-08-15 | OpenSynergy GmbH | Method for synchronizing a service between a service provider and a service consumer and system |
| JP2019202704A (ja) * | 2018-05-25 | 2019-11-28 | 川崎重工業株式会社 | 乗物設定変更システム、変更装置、変更指示プログラム、及び乗物設定変更方法 |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5794164A (en) * | 1995-11-29 | 1998-08-11 | Microsoft Corporation | Vehicle computer system |
| JP2008019843A (ja) | 2006-07-14 | 2008-01-31 | Yamaha Motor Co Ltd | エンジンセッティングシステムおよびそれに用いられるサーバ装置 |
| JP5081779B2 (ja) | 2008-09-30 | 2012-11-28 | 株式会社ケーヒン | エンジンセッティングシステム及びエンジンセッティング方法 |
| JP5549854B2 (ja) * | 2009-04-14 | 2014-07-16 | ソニー株式会社 | 情報処理装置および方法、並びにプログラム |
| WO2012140671A2 (en) * | 2011-04-11 | 2012-10-18 | Ineda Systems Pvt. Ltd | File system sharing |
| US10824330B2 (en) * | 2011-04-22 | 2020-11-03 | Emerging Automotive, Llc | Methods and systems for vehicle display data integration with mobile device data |
| US8918231B2 (en) | 2012-05-02 | 2014-12-23 | Toyota Motor Engineering & Manufacturing North America, Inc. | Dynamic geometry support for vehicle components |
| CN102902513B (zh) * | 2012-09-03 | 2015-12-02 | 哈尔滨工程大学 | 一种提高嵌入式操作系统并行处理实时性的软硬件混合式结构 |
| WO2014172321A1 (en) * | 2013-04-15 | 2014-10-23 | Flextronics Ap, Llc | Access and portability of user profiles stored as templates |
| US20140310277A1 (en) * | 2013-04-15 | 2014-10-16 | Flextronics Ap, Llc | Suspending user profile modification based on user context |
| WO2014172312A2 (en) * | 2013-04-15 | 2014-10-23 | Flextronics Ap, Llc | User interface and virtual personality presentation based on user profile |
| US10068377B2 (en) * | 2016-03-24 | 2018-09-04 | Toyota Jidosha Kabushiki Kaisha | Three dimensional graphical overlays for a three dimensional heads-up display unit of a vehicle |
| CN107241651B (zh) * | 2016-03-28 | 2021-02-26 | 斑马智行网络(香港)有限公司 | 一种媒体数据播放方法和装置、智能终端 |
| US11373459B2 (en) * | 2016-11-15 | 2022-06-28 | Runway Growth Credit Fund Inc. | Program and vehicle interaction |
| US10150478B2 (en) * | 2017-04-27 | 2018-12-11 | Honda Motor Co., Ltd. | System and method for providing a notification of an automated restart of vehicle movement |
| US10564954B2 (en) * | 2017-10-11 | 2020-02-18 | Ford Global Technologies, Llc | Hybrid electric vehicle with automated software update system |
| US20190143997A1 (en) * | 2017-11-14 | 2019-05-16 | Ford Global Technologies, Llc | Automated vehicle configuration |
| US11285896B2 (en) * | 2018-06-05 | 2022-03-29 | Toyota Motor Engineering & Manufacturing North America, Inc. | System and method for vehicle sharing |
| US11042341B2 (en) * | 2019-01-04 | 2021-06-22 | Byton North America Corporation | Integrated functionality of center display, driver display, and shared-experience display |
| US11057673B2 (en) * | 2019-01-22 | 2021-07-06 | International Business Machines Corporation | Personalized content aggregation and delivery |
-
2020
- 2020-05-28 US US16/885,824 patent/US11403155B2/en active Active
- 2020-06-18 EP EP20180828.4A patent/EP3882765A1/en active Pending
- 2020-06-23 JP JP2020107662A patent/JP7051939B2/ja active Active
- 2020-06-29 KR KR1020200079252A patent/KR102371527B1/ko active IP Right Grant
- 2020-07-31 CN CN202010762116.4A patent/CN111880951B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2015528673A (ja) * | 2012-08-31 | 2015-09-28 | トウェドル グループ | 自動車ヘッドユニットを伴った通信およびサービスを提供するためのシステム、方法、および物品 |
| US20170080949A1 (en) * | 2015-09-21 | 2017-03-23 | Honda Motor Co., Ltd. | System and method for applying vehicle settings in a vehicle |
| EP3361711A1 (en) * | 2017-02-08 | 2018-08-15 | OpenSynergy GmbH | Method for synchronizing a service between a service provider and a service consumer and system |
| JP2019202704A (ja) * | 2018-05-25 | 2019-11-28 | 川崎重工業株式会社 | 乗物設定変更システム、変更装置、変更指示プログラム、及び乗物設定変更方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3882765A1 (en) | 2021-09-22 |
| CN111880951B (zh) | 2024-01-23 |
| US20210294677A1 (en) | 2021-09-23 |
| CN111880951A (zh) | 2020-11-03 |
| JP7051939B2 (ja) | 2022-04-11 |
| US11403155B2 (en) | 2022-08-02 |
| KR102371527B1 (ko) | 2022-03-07 |
| JP2021147027A (ja) | 2021-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6434459B2 (en) | Automobile information system | |
| CN111542807B (zh) | 用于车辆系统总线的可扩展映射 | |
| KR102262926B1 (ko) | 차량용 소프트웨어 제어 장치 | |
| JP7043563B2 (ja) | 車両のための拡張可能なコンピューティングアーキテクチャ | |
| CN109981434A (zh) | 一种车载智能系统 | |
| KR102371527B1 (ko) | 차량용 운영 체제와 차량 제조업체 사용자 관리 시스템의 통합 | |
| CN113448643A (zh) | 配置数据管理系统及方法 | |
| EP4369186A1 (en) | Control method and apparatus, device, and storage medium | |
| US20230007460A1 (en) | Method and system for segmenting and transmiting data between computing devices and vehicle head units | |
| US20240069928A1 (en) | Network management for vehicle operating systems | |
| US20230376307A1 (en) | Streaming via hardware abstraction layer | |
| JP7484746B2 (ja) | 車両用装置、車両用システム | |
| JP2022114164A (ja) | 車両用装置、車両用システム、外部装置 | |
| CN117075834A (zh) | 一种应用于汽车的多系统融合显示方法 | |
| JP2024061957A (ja) | 車載装置、プログラム提供装置、車両用システム、機能部制御方法、プログラム保存方法及びプログラム提供方法 | |
| CN115734197A (zh) | 一种车载驾乘人员辅助设备间交互的方法、装置和系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant |