WO2022114291A1 - 차량 가상화 구조 기반의 시스템 제어 방법 및 장치 - Google Patents

차량 가상화 구조 기반의 시스템 제어 방법 및 장치 Download PDF

Info

Publication number
WO2022114291A1
WO2022114291A1 PCT/KR2020/017113 KR2020017113W WO2022114291A1 WO 2022114291 A1 WO2022114291 A1 WO 2022114291A1 KR 2020017113 W KR2020017113 W KR 2020017113W WO 2022114291 A1 WO2022114291 A1 WO 2022114291A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
container
upgrade
containers
output information
Prior art date
Application number
PCT/KR2020/017113
Other languages
English (en)
French (fr)
Inventor
김용경
이원
최현덕
홍예브게니
Original Assignee
주식회사 드림에이스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 드림에이스 filed Critical 주식회사 드림에이스
Priority to JP2023544019A priority Critical patent/JP2023543957A/ja
Priority to PCT/KR2020/017113 priority patent/WO2022114291A1/ko
Priority to US18/029,127 priority patent/US20230367579A1/en
Publication of WO2022114291A1 publication Critical patent/WO2022114291A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • An embodiment of the present invention relates to a system control method and apparatus based on a vehicle virtualization structure.
  • a plurality of display devices exist in a vehicle, and a plurality of software for executing the display devices exist.
  • the degree of freedom for a user or a passenger in a vehicle to use a plurality of display devices is improved.
  • the embodiment may provide a system control method and apparatus based on a vehicle virtualization structure capable of saving disk resources.
  • a vehicle virtualization structure-based control method includes booting a plurality of containers; confirming the necessity of upgrading the plurality of containers; and performing an upgrade for the plurality of containers in response to the need for the upgrade, wherein the plurality of containers share system initialization and management.
  • the confirming of the necessity of upgrading the plurality of containers may include: receiving upgrade information; comparing the upgrade information with the upgrades of the plurality of containers; and determining the need for the upgrade.
  • the method may further include; driving the plurality of containers when there is no need for the upgrade.
  • the method may further include a step of determining whether the upgrade is for a system directory or an upgrade for user data (personal data) when there is a need for the upgrade.
  • Rebooting the plurality of containers may further include, and return to the step of confirming the need for the upgrade.
  • the method may further include, after the step of driving the plurality of containers, the step of executing an application on a display connected to the container.
  • the plurality of containers may be driven by copying a change directory among the user data.
  • the shared system initialization and management may include a kernel, a distro, and a library.
  • the vehicle virtualization structure-based control method includes: recognizing a user in driving a container after the above-described update and the like; and confirming whether the recognized user is a pre-registered user.
  • the step of performing registration may further include.
  • Setting a vehicle environment when the recognized user is the previously registered user; Checking whether the web account is registered; may further include.
  • the method may further include; if there is registration of the web account, determining whether the web account is logged in to another web platform container.
  • the method may further include outputting termination or re-login when the web account is logged in to another web platform container.
  • extracting a preferred application when the web account is not logged into another web platform container; ; may be further included.
  • Displaying a favorite destination by driving navigation may further include.
  • a vehicle virtualization structure-based sound control method comprises: receiving at least one of first sound output information from a first sound client and second sound output information from a second sound client; comparing the priorities of the received first sound output information and the second sound output information; and transmitting at least one of the first sound output information and the second sound output information to hardware in response to the comparison result, wherein the first sound client and the second sound client are mounted on different virtual engines. do.
  • the first sound client may be mounted on a cluster operating system
  • the second sound client may be mounted on an audio video navigation (AVN) operating system, a co-driver operating system, and a rear seat entertainment (RSE) operating system.
  • APN audio video navigation
  • RSE rear seat entertainment
  • the priority of the first sound output information may be higher than that of the second sound output information.
  • the method may further include, after the step of comparing the priorities, whether the generation time of the first sound output information is the driving of the vehicle.
  • the method may further include outputting the first sound output information and then outputting the second sound output information if the generation time of the first sound output information is not while the vehicle is driving.
  • If the generation time of the first sound output information is when the vehicle is driving, adjusting and outputting whether the first sound output information and the second sound output information are output and output time according to the level of the first sound output information; may include
  • the level of the output information includes a first level and a second level lower than the first level, and when the level of the first sound output information is the first level, only the first sound output information is output, and the second sound It may further include; blocking the output of the output information.
  • the second sound output information may be transmitted to the hardware in the transmitting step.
  • a vehicle virtualization structure-based sound control apparatus includes: a receiver configured to receive at least one of first sound output information from a first sound client and second sound output information from a second sound client; a comparison unit for comparing priorities of the received first sound output information and the second sound output information; and a transmitter for transmitting at least one of the first sound output information and the second sound output information to hardware in response to the comparison result, wherein the first sound client and the second sound client are mounted on different virtual engines.
  • a system control method and apparatus based on a vehicle virtualization structure capable of saving disk resources may be implemented.
  • FIG. 1 is a conceptual diagram of a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 2 is a detailed block diagram of a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 3 is a flowchart of a system control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 4 is a detailed flowchart for confirming the necessity of an upgrade in a system control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 5 is a detailed flowchart of a system control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 6 is a conceptual diagram of a structure of a plurality of containers in a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 7 and 8 are diagrams for explaining driving a plurality of containers in a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 10 is a flowchart of a web platform control method in a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 11 is a diagram illustrating driving of a web application in a web platform control method in a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 12 is a conceptual diagram of a system based on a vehicle virtualization structure according to another embodiment
  • FIG. 13 is a view for explaining a display device in a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 14 is a block diagram of a sound control device based on a vehicle virtualization structure according to an embodiment
  • FIG. 15 is a flowchart of a sound control method based on a vehicle virtualization structure according to an embodiment
  • 16 is a detailed flowchart of a sound control method based on a vehicle virtualization structure according to an embodiment
  • 17 is a view for explaining the output of the first sound output information and the second sound output information for an example
  • 19 is a view for explaining the output of the first sound output information and the second sound output information for another example.
  • 20 is a conceptual diagram of a system based on a vehicle virtualization structure according to a modification.
  • Terms including an ordinal number such as second, first, etc. may be used to describe various elements, but the elements are not limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
  • the second component may be referred to as the first component, and similarly, the first component may also be referred to as the second component. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.
  • An embodiment of the present disclosure relates to a vehicle streaming control apparatus and control method for a vehicle, vehicle infotainment, etc.
  • an application 'app', 'application', application in the same sense
  • the vehicle infotainment and The content is to provide an integrated system environment.
  • these contents do not limit the rights of this patent.
  • an important function related to vehicle control is performed while providing a vehicle infotainment function.
  • the functions related to vehicle control include applications including navigation systems that affect the user's vehicle operation, cluster systems that indicate vehicle speed or RPM, etc., and autonomous control vehicle autonomy. It also includes important functions related to the life of the occupants, such as control systems. And while the display of these applications is done freely, there should be no interference with driving such as vehicle control. In other words, the protection of vehicle driving must be kept essential. If this protection is not provided, accidents may occur.
  • streaming in the vehicle is performed within a range that does not interfere with driving, so that services and applications related to entertainment, such as audio reproduction, video reproduction, and game execution, access to vehicle occupants including the driver. and operation can be made easily.
  • FIG. 1 is a conceptual diagram of a system based on a vehicle virtualization structure according to an embodiment
  • FIG. 2 is a detailed block diagram of a system based on a vehicle virtualization structure according to an embodiment.
  • a system based on a vehicle virtualization structure includes hardware (not shown), a base operating system 10 mounted on hardware (not shown), and a base operating system 10 .
  • CM container manager
  • At least one operating system will be described below as a 'container'.
  • hardware may be a concept including a processor, a display unit, a storage unit, a memory unit, a control unit, and an I/O device.
  • the driving unit CP is a system area mounted or driven on the first virtual engine 20a
  • the infotainment unit IP, Infotainment Platform
  • the infotainment unit IP, Infotainment Platform
  • It may be a system area mounted or driven on the virtual engine 20b. Due to this configuration, even if an upgrade or other malfunction occurs in the infotainment unit IP, the driving unit CP may not be affected. That is, the influence while driving can be minimized.
  • a web platform unit may be mounted or driven on the base operating system 10 and the additional virtual engine 20 .
  • the platform unit (Web Platform) may share the container manager with the infotainment unit (IP).
  • the platform unit (Web Platform) may be configured as a part of the infotainment unit (IP).
  • the platform unit is a set of software installed on one operating system (eg, container, 30), the operating system mounted on the container management unit, such as the infotainment unit (IP), and including middleware and important applications, and a plurality of operating system platforms (
  • the AGL 40 may include a plurality of applications (eg, web applications 50 ) running on the operating system platform 40 .
  • the base operating system 10 may be, for example, various operating systems.
  • the base operating system 10 may include Linux, a hypervisor, QNX, GENIVI, and the like.
  • the first virtual engine 20a and the second virtual engine 20b are middleware solutions or various platforms, and may be developed in mobile and C language.
  • the first virtual engine 20a and the second virtual engine 20b may provide a plurality of built-in libraries, and may perform the same operation in various mobile terminals.
  • the first virtual engine 20a and the second virtual engine 20b may be a Linux-based Android kernel, and may initialize memory protection, a virtual memory module, and schedule caching.
  • the at least one container 30a to 30d may be mounted on the second virtual engine 20a and not mounted on the first virtual engine 10a. Accordingly, since the security of the driving unit CP is improved, driving stability may also be improved.
  • At least one container 30a to 30d may be a schedule of process virtualization as a form of a virtualization method in an embodiment.
  • virtualization technology using containers divides the inside of the host OS (operating system) into a kernel space that manages physical resources and a user space that executes a user process, that is, an application program (application, application, APP), and divides the user space into a user space. It may refer to a technology for allocating and sharing hardware resources used in each user process by dividing it into several pieces.
  • the containers 30a to 30d may convert the called library to be interfaced with the system library to perform connection or compatibility between the base operating system and a plurality of operating system platforms.
  • the plurality of operating system platforms 40a to 40f may be mounted on a container.
  • the plurality of operating system platforms 40a to 40f may include Android, Automotive Grade Linux (AGL), a web platform, a cluster platform, a head-up display (HUD) platform, and the like.
  • the at least one application 50a to 50d is an application program other than a system program, and may include Audio Video Navigation (AVN), Co-Driver, Rear Seat Entertainment (RSE), and the like in the vehicle.
  • AVN Audio Video Navigation
  • RSE Rear Seat Entertainment
  • the plurality of displays 60a to 60f may display the operating system platform 40a to 40f or an application program on the platform to a user (eg, a passenger).
  • the plurality of displays 60a to 60f may include various display devices (eg, OLEDs).
  • the container manager CM may manage environments for the plurality of operating systems 30a to 30d on the virtual engines 20a to 20b. That is, the container management unit CM may perform resource allocation for containers, streaming connection, update, display output, connection with the output unit, and the like, for example, of the plurality of operating systems 30a to 30d . A detailed description thereof will be given later.
  • the container management unit CM may include a container control unit CM1 , a container upgrade unit CM2 , a container state management unit CM3 , a web platform container management unit CM4 , and a container bridge unit CM5 .
  • the container control unit CM1 may perform system resources allocated to containers, resource policies, streaming control, output to a display, file system management, and the like.
  • the container control unit CM1 includes a container resource management unit M1-1, a display control unit M1-2, a container policy management unit M1-3, a container file system management unit M1-4, and a container streaming management unit M1-5. ) and an audio policy and control management unit M1-6.
  • the container resource management unit M1-1 may dynamically allocate system resources allocated to containers. For example, the container resource management unit M1-1 may collect resource usage to prevent QoS performance degradation due to resource shortage. For example, the container resource management unit M1-1 may set a container allocated to a dedicated core by using a preset container priority, a resource usage threshold, and a monitoring and monitoring period.
  • the container policy management unit M1-3 may include information on priorities allocated to dedicated cores among the aforementioned containers.
  • the display control unit M1-2 may manage the containers responsible for the operation of each of the plurality of displays to output a screen to each display in the vehicle.
  • the container file system manager M1-4 may systematically and efficiently manage files necessary for operation of each container in a plurality of container environments.
  • the container file system manager M1-4 may overlay a file system of a container with another container file system as an example of any one file system, as will be described later. Accordingly, a user (a plurality of passengers) can easily share a file system such as a container with other users or other locations (eg, seats).
  • a plurality of containers may share system initialization and management.
  • a plurality of containers may share rootfs.
  • each operating system ie, container, stores or copies (copy) a separate change directory, so that resources such as disk can be efficiently used.
  • the upgrade for each container may also be performed using only the change directory. For example, each display device can be effectively upgraded.
  • the container streaming management unit M1-5 may manage the movement of images output from each display, and the like. That is, the container streaming management unit M105 may determine whether streaming is possible according to each policy of the driving unit, the infotainment unit, and the display.
  • the audio policy and control manager M1 - 6 may control audio output by reflecting a policy on audio output between at least one container. A detailed description thereof will be given later.
  • the container upgrade unit CM2 may perform an upgrade for each operating system of the infotainment unit including a plurality of operating systems. For example, the container upgrade unit CM2 may easily upgrade each container of the infotainment unit composed of containers.
  • the container upgrade unit CM2 may include an update and confirmation management unit M2-1 and an authentication management unit M2-2.
  • the update and check management unit M2-1 may check an identifier for each container for a container requiring an update among a plurality of containers and a normal operation check after the update.
  • the authentication management unit M2-2 may perform authentication and version comparison for each vehicle and container in order to perform the update.
  • the container state management unit CM3 may manage the states of a plurality of containers, such as checking whether the container operates normally.
  • the container state management unit CM3 may include a state management unit M3-1 and a log management unit M3-2.
  • the state management unit M3-1 may check whether the container and functions of the container management unit operate normally through periodic monitoring.
  • the log management unit M3-2 may keep a log of the contents checked through the container state management unit. Furthermore, the log management unit M3 - 2 may delete or backup the log after a predetermined time. Furthermore, when the container operates abnormally, the state management unit M3-1 can easily solve the problem through the log management unit M3-2.
  • the web platform container management unit CM4 may manage the web platform container, and may include a web platform management unit M4-1 and a web account management unit M4-2.
  • the web platform management unit M4-1 may manage whether various functions of the web platform operate normally on the operating system, that is, the container. In addition, when a plurality of web platform containers operate, the web platform management unit M4-1 may manage a login account for each container to manage a personalized web use environment. A detailed description thereof will be given later.
  • the container bridge unit CM5 may be connected to an interface, hardware, etc. to perform interconnection between respective operating systems for display, audio, application, network, and the like.
  • a user may operate a vehicle virtualization structure-based system through a user interface or the like.
  • the manipulation process or result may be provided to the user through an output device such as a display or audio.
  • the feedback may be provided through an input such as a user manipulating a touch on the display.
  • FIG. 3 is a flowchart for a system control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 4 is a detailed flowchart for confirming the necessity of an upgrade in a system control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 5 is an implementation It is a detailed flowchart of a system control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 6 is a conceptual diagram of a structure of a plurality of containers in a system based on a vehicle virtualization structure according to an embodiment
  • FIGS. 7 and 8 are in the embodiment It is a diagram for explaining driving a plurality of containers in a system based on a vehicle virtualization structure.
  • the vehicle virtualization structure-based system control method includes booting a plurality of containers ( S310 ), confirming the necessity of upgrading the plurality of containers ( S320 ), and providing a plurality of containers in response to the need for upgrade. It may include the step of performing the upgrade (S330).
  • a plurality of containers may share system initialization and management as described above.
  • a plurality of containers may share a shared system initialization and management rootfs. That is, the plurality of containers Container1 to Container 3 may share a kernel, a distro, and a library with each other.
  • the vehicle virtualization structure-based system control method may be performed by the above-described container management unit (CM). That is, the system control device based on the vehicle virtualization structure may include a container management unit (CM). Furthermore, the vehicle virtualization structure-based system control device may include a container control unit CM1 and a container upgrade unit CM2, and may perform each control step to be described later. Hereinafter, the apparatus in which each step is performed will be briefly described.
  • the container controller may boot a plurality of containers ( S310 ).
  • the container upgrade unit CM2 may determine the necessity of upgrading the operating system, that is, the plurality of booted containers ( S320 ).
  • confirming the necessity of upgrading the plurality of containers includes receiving upgrade information (S321), comparing the upgrade information with the upgrades of the plurality of containers (S322), and determining the need for upgrade (S323) ) may be included.
  • the container upgrade unit CM2 may receive update information from a server or the like.
  • the update information may include version information of the corresponding container.
  • the container management unit CM or the container upgrade unit CM2 may compare the received upgrade with upgrade information of a plurality of containers, that is, upgrade information. Accordingly, by comparing the received upgrade information with the upgrade information of the corresponding container, it may be determined whether the upgrade information of the container is newer than the received upgrade information.
  • the container management unit CM or the container upgrade unit CM2 may determine that there is no need to upgrade. Also, when the received upgrade information is a version lower than the container upgrade information, it may be determined that the upgrade is necessary. That is, it may be determined whether there is a need to upgrade a plurality of containers ( S334 ).
  • the container management unit CM may perform an upgrade for a plurality of containers in response to the need for upgrade (S330). Only when there is a need for upgrade, the container management unit CM may perform the upgrade for a plurality of containers. And when there is no need for upgrading, the container controller CM1 may drive a plurality of containers ( S340 ). That is, the container can be driven by loading personal data for each display.
  • the container management unit (CM) or the container control unit (CM1) shares the system initialization and manager rootfs in each display-specific container in the vehicle, and each container (eg, each display) shares user data. By overlaying rootfs, you can save disk resources. Accordingly, efficient container operation or driving can be achieved.
  • the container may be driven by copying user data.
  • a plurality of containers may be driven or executed by copying a change directory among user data. That is, the latest version of the user data delta0/ may be copied as the new user data delta1/. Accordingly, a new container (snap clone) can be easily driven after the existing container (original) is driven. For example, a container for a plurality of RSE displays may be more easily driven.
  • the existing latest version of user data or driven user data (new files) may be overlaid on the shared rootfs (root files) as described above (mount). In this way, both driving and updating of the container (system files and user data) can be made easily.
  • the container management unit CM or the container control unit CM1 may execute an application through a display connected to the container ( S350 ). Accordingly, each service (eg, application execution) for each display located in each occupant in the vehicle may be provided to the occupant.
  • the container management unit CM or the container control unit CM1 may determine whether it is an upgrade for the system directory or an upgrade for personal data when there is a need for an upgrade ( S360 ). This may be a step in which the step ( S330 ) of performing the upgrade for a plurality of containers in response to the above-described need for upgrading is specified. That is, the upgrade of the container may be embodied as follows.
  • the container management unit CM may perform user authentication after determining whether it is an upgrade (S360) (S370) and receive the system directory (S380).
  • the container management unit CM or the container upgrade unit CM2 may perform user authentication.
  • User authentication may include authentication for vehicles and containers. That is, after determining the type of vehicle and the type of container, authentication of the container corresponding to the vehicle may be performed ( S370 ).
  • the container management unit CM or the container upgrade unit CM2 may receive the latest version of the file system from the server.
  • a kernel, OS, and library exist as a file system.
  • the received file system can be applied to the shared rootfs. That is, the vehicle virtualization structure-based control method and apparatus according to the embodiment can easily perform system directory upgrade for the same container type on the same virtual engine by the container manager (or including the container manager). That is, the system directory upgrade for a plurality of containers may be performed by receiving the system directory once. Thereafter, the plurality of containers may be rebooted (S390).
  • a plurality of containers may be driven after determining whether the upgrade is an upgrade ( S360 ) ( S340 ).
  • the latest means a case in which the preservation is higher or the date of modification is the closest.
  • the latest user data can be applied to each container.
  • user data can be loaded and individual containers can be driven. Accordingly, it is possible to minimize the use of disk resources.
  • the container manager CM may execute an application through a display connected to the container ( S350 ). That is, the application may be driven on each container and output through each display. Accordingly, each service (eg, application execution) for each display located in each occupant in the vehicle may be provided to the occupant.
  • FIG. 9 is an enlarged view of part K in FIG. 2
  • FIG. 10 is a flowchart for a web platform control method in a vehicle virtualization structure-based system according to an embodiment
  • FIG. 11 is a vehicle virtualization structure-based system according to an embodiment It is a diagram showing the driving of a web application in a web platform control method.
  • the vehicle virtualization structure-based system includes a web platform mounted or driven on the base operating system 10 and the additional virtual engine 20 .
  • the platform unit (Web Platform) may share the container manager with the infotainment unit (IP).
  • the platform unit (Web Platform) may be configured as a part of the infotainment unit (IP). As mentioned above, this will be described as an individual configuration.
  • the platform unit is one operating system (eg, container, 30) mounted on the container management unit like the infotainment unit (IP), a software set mounted on the operating system and including middleware and important applications, a plurality of operating systems It may include a platform (eg, AGL, 40 ) and a plurality of applications (eg, web application, 50 ) running on the operating system platform 40 .
  • a platform eg, AGL, 40
  • applications eg, web application, 50
  • the virtual engine 20 may include a vehicle information service server (VIS server).
  • the vehicle information service server (Vehicle Information Service Sever, VIS server) stores vehicle driving unit information (speed, fuel amount, etc.) and vehicle setting information (temperature, seat position, etc.) and transmits it to each web platform container, that is, the operating system platform 40. have. That is, the vehicle information service server (Vehicle Information Service Sever, VIS server) is requested by the vehicle information service client (Vehicle Information Service Sever, VIS Client) in each web operating system platform 40 or vehicle driving unit information corresponding to the occupant and vehicle You can provide configuration information.
  • the container manager CM may include the web platform container manager CM4 as described above.
  • the web platform container management unit CM4 may manage the web platform container, and may include a web platform management unit and a web account management unit.
  • the web platform management unit may manage whether various functions of the web platform operate normally on the operating system, that is, the container. In addition, when a plurality of web platform containers operate, the web platform management unit may manage a login account for each container to manage a personalized web use environment.
  • the operating system platform 40 is an AGL, and may include a vehicle information service server (VIS Client) that receives requested or corresponding vehicle driver information and vehicle setting information and sets a vehicle environment.
  • VIS Client vehicle information service server
  • the operating system platform 40 drives an API service unit for user recognition and registration (Device API service), and a plurality of web platform containers (operating system) 30 to expand the function of managing web applications included in the operating system platform. It includes an add-on unit (WAM add on) that monitors and manages whether a plurality of web applications can use hardware resources such as GPS, and a virtual keyboard unit (Virtual Keyboard) for text input when using web applications. can do.
  • WAM add on add-on unit that monitors and manages whether a plurality of web applications can use hardware resources such as GPS, and a virtual keyboard unit (Virtual Keyboard) for text input when using web applications. can do.
  • the vehicle virtualization structure-based control method may include recognizing a user in relation to web platform control (S405) and checking whether the recognized user is a previously registered user (S410). have.
  • the operating system platform 40 or the API service unit may recognize the user (S405).
  • individual recognition of each occupant in the vehicle can be made.
  • User recognition may be performed through various devices (sensor, mobile, application, etc.).
  • the step of recognizing the user ( S405 ) may be performed after the aforementioned update and container operation.
  • the step of recognizing the user ( S405 ) may be performed after the application is driven on each container and output to each display ( S350 ). In this case, the user of the vehicle occupant may drive the web platform container and user recognition may be performed.
  • the operating system platform 40 or the API service unit may check whether the recognized user is a pre-registered user (S410). If the operating system platform 40 or the API service unit (Device API service) is not a previously registered user, the user registration may be performed (S415), and in the case of the previously registered user, the vehicle environment may be set (S420) .
  • the environment may include seat position, preferred temperature, lighting conditions, and the like.
  • CM container management unit
  • CM4 web platform container management unit
  • the web platform container management unit (CM4) manages web account registration, change, deletion, etc., can confirm that the web account is a registered account, executes and manages the application list for each web account, or does not cause duplicate web account logins You can manage the login status to prevent it from happening. That is, user information provided from the operating system platform 40 or the API service unit (Device API service) is checked in the container management unit (CM), and an application list execution and management for each account or duplicate login management can be performed.
  • the container management unit (CM) authentication web platform container management unit (CM4) may check whether a web account is registered for the recognized user, that is, user information (S425).
  • the container management unit (CM) authentication web platform container management unit (CM4) registers and stores a web account (S430) if the web account for the user is not registered or does not exist, and when the web account is registered, the web account is It can be checked whether the user is logged in to another web platform container (S435).
  • the container management unit (CM) authentication web platform container management unit (CM4) outputs termination or re-login when the web account is logged in to another web platform container (S440), but if the web account is not logged in, each web account
  • the application may be extracted (S445).
  • the extracted preferred application for each web account may be provided to the user (refer to FIG. 11 ). Accordingly, the user can easily recognize the preferred or real-time web application operation for each web account.
  • the container management unit (CM) increase web platform container management unit (CM4) may drive the navigation application and display the destination on the display (S450). And the user can input a destination through the virtual keyboard unit (Virtual Keyboard) (S455).
  • the web platform application is easily used according to user recognition, and the same application is applied to each operating system (web platform container). can run with different user or passenger web accounts. Accordingly, the same application can be driven and executed using individual accounts between passengers in the vehicle.
  • FIG. 12 is a conceptual diagram of a system based on a vehicle virtualization structure according to another embodiment
  • FIG. 13 is a view for explaining a display device in a system based on a vehicle virtualization structure according to an embodiment.
  • the vehicle virtualization structure-based system includes hardware (not shown), the base operating system 10 mounted on the hardware (not shown), and the base operating system.
  • CM container management unit
  • At least one operating system will be described below as a 'container'.
  • hardware may be a concept including a processor, a display unit, a storage unit, a memory unit, a control unit, and an I/O device.
  • the driving unit CP is a system area mounted or driven on the first virtual engine 20a
  • the infotainment unit IP, Infotainment Platform
  • the infotainment unit IP, Infotainment Platform
  • It may be a system area mounted or driven on the virtual engine 20b. Due to this configuration, even if an upgrade or other malfunction occurs in the infotainment unit IP, the driving unit CP may not be affected. That is, the influence while driving can be minimized.
  • a web platform unit may be mounted or driven on the base operating system 10 and the additional virtual engine 20 .
  • the platform unit (Web Platform) may share the container manager with the infotainment unit (IP).
  • the platform unit (Web Platform) may be configured as a part of the infotainment unit (IP).
  • the platform unit is a set of software installed on one operating system (eg, container, 30), the operating system mounted on the container management unit, such as the infotainment unit (IP), and including middleware and important applications, and a plurality of operating system platforms (
  • the AGL 40 may include a plurality of applications (eg, web applications 50 ) running on the operating system platform 40 .
  • the base operating system 10 may be, for example, various operating systems.
  • the base operating system 10 may include Linux, a hypervisor, QNX, GENIVI, and the like.
  • the first virtual engine 20a and the second virtual engine 20b are middleware solutions or various platforms, and may be developed in mobile and C language.
  • the first virtual engine 20a and the second virtual engine 20b may provide a plurality of built-in libraries, and may perform the same operation in various mobile terminals.
  • the first virtual engine 20a and the second virtual engine 20b may be a Linux-based Android kernel, and may initialize memory protection, a virtual memory module, and schedule caching.
  • the at least one container 30a to 30d may be mounted on the second virtual engine 20a and not mounted on the first virtual engine 10a. Accordingly, since the security of the driving unit CP is improved, driving stability may also be improved.
  • At least one container 30a to 30d may be a schedule of process virtualization as a form of a virtualization method in an embodiment.
  • virtualization technology using containers divides the inside of the host OS (operating system) into a kernel space that manages physical resources and a user space that executes user processes, that is, applications (applications, applications, APPs), and divides the user space into user space. It may refer to a technology for allocating and sharing hardware resources used in each user process by dividing it into several pieces.
  • the containers 30a to 30d may convert the called library to be interfaced with the system library to perform connection or compatibility between the base operating system and a plurality of operating system platforms.
  • the plurality of operating system platforms 40a to 40f may be mounted on a container.
  • the plurality of operating system platforms 40a to 40f may include Android, Automotive Grade Linux (AGL), a web platform, a cluster platform, a head-up display (HUD) platform, and the like.
  • a plurality of sound clients may be disposed in the operating system platform 40 .
  • the plurality of sound clients may include a first sound client and a second sound client.
  • the first sound client may be mounted on the operating system platforms 40a and 40b on the first virtual engine 20a.
  • the second sound client may be mounted on the operating system platform 40c or the like on the second virtual engine 20b. That is, the first sound client and the second sound client may be mounted on different virtual engines.
  • the first sound client may be mounted on the cluster operating system (40a) or the HUD operating system (40b).
  • the second sound client may be mounted on an Audio Video Navigation (AVN) operating system, a Co-Driver operating system, and a Rear Seat Entertainment (RSE) operating system.
  • APN Audio Video Navigation
  • Co-Driver operating system
  • RSE Rear Seat Entertainment
  • the sound server may receive the first sound output information and the second sound output information from the first sound client SC1 and the second sound client SC2, respectively.
  • the sound server may be mounted in the virtual engines 20a and 20b or in the base operating system 10 .
  • the sound server includes a first sound server (SS1) and a second sound server (SS2), and the first sound server (SS1) and the second sound server (SS2) are mounted on a heterogeneous virtual engine.
  • the at least one application 50a to 50d is an application program other than a system program, and may include Audio Video Navigation (AVN), Co-Driver, Rear Seat Entertainment (RSE), and the like in the vehicle.
  • AVN Audio Video Navigation
  • RSE Rear Seat Entertainment
  • the plurality of displays 60a to 60f may display the operating system platform 40a to 40f or an application program on the platform to a user (eg, a passenger).
  • the plurality of displays 60a to 60f may include various display devices (eg, OLEDs).
  • the following description may relate to the above-described audio policy and control management unit.
  • a user may operate a vehicle virtualization structure-based system through a user interface or the like.
  • the manipulation process or result may be provided to the user through an output device such as a display or audio.
  • FIG. 14 is a block diagram of a sound control apparatus based on a vehicle virtualization structure according to an embodiment
  • FIG. 15 is a flowchart of a sound control method based on a vehicle virtualization structure according to an embodiment
  • FIG. 16 is a vehicle virtualization structure based according to an embodiment is a detailed flowchart of a sound control method of
  • FIG. 17 is a diagram for explaining the output of the first sound output information and the second sound output information for one example
  • FIG. 18 is the first sound output information and the second sound output information for another example It is a view for explaining the output of sound output information
  • FIG. 19 is a view for explaining the output of the first sound output information and the second sound output information for another example.
  • the sound control apparatus 100 based on the vehicle virtualization structure may include a receiving unit 110 , a comparing unit 120 , a determining unit 130 , and a transmitting unit 140 .
  • the vehicle virtualization structure-based sound control device 100 includes an audio policy and control management unit, and the audio policy and control management unit includes a receiver 110 , a comparison unit 120 , a determination unit 130 , and a transmitter 140 . ) can be matched.
  • the receiver 110 may receive sound output information from each sound client.
  • the receiver 110 may receive at least one of the first sound output information from the first sound client and the second sound output information from the second sound client.
  • the sound output information may be generated by a user input or the like. That is, the sound output information may include sound information output while an application is executed by a user input.
  • the comparison unit 120 may compare the priority of the received first sound output information and the second sound output information.
  • the priority of the first sound output information may be higher than that of the second sound output information. Accordingly, since the sound output information received from the driving unit has a higher priority than the sound output information received from the infotainment unit, driving stability can be improved.
  • the determination unit 130 may determine whether the first sound output information is generated when the vehicle is driving. In this case, the determination unit 130 may determine to output the second sound output information after outputting the first sound output information.
  • the determination unit 130 adjusts whether the first sound output information and the second sound output information are output and outputs the output time according to the level of the first sound output information. can be judged to be
  • the determination unit 130 may determine to output only the first sound output information and block the output of the second sound output information.
  • the level of the output information may include a first level and a second level lower than the first level.
  • the determination unit 130 may output the first sound output information and the second sound output information for a first time. Also, the determination unit 130 may determine to output the second sound output information for a second time continuous to the first time. In this case, the size of the first sound output information for the first time may be greater than the size of the second sound output information.
  • a sound client in a virtual engine (virtualization environment) or an operating system (eg, guest operating system, etc.) mounted (or embedded) in the host operating system may receive or request sound output information from a display device connected to each operating system or the like. Receiving and requesting sound output information may mean sound data for which output is requested.
  • the sound server mounted in the virtual engine or container or the base operating system may receive data, ie, sound output information, and transmit the sound output information to hardware to output sound through a speaker, which is an output interface, or the like.
  • the sound output information that is, data may be transmitted to the display device through a sound client in the virtual engine or a sound client installed (or embedded) in the host operating system (eg, guest operating system, etc.) to be provided to the user.
  • the transmitter 140 may transmit at least one of the finally determined first sound output information and the second sound output information to hardware or the like. Through this, sound may be output through a front or rear sound output device (eg, a speaker) of the vehicle.
  • a front or rear sound output device eg, a speaker
  • the method for controlling a sound based on a vehicle virtualization structure includes receiving at least one of first sound output information from a first sound client and second sound output information from a second sound client (S510), comparing the priorities of the received first sound output information and the second sound output information (S520), and at least one of the first sound output information and the second sound output information in response to the comparison result may include a step (S530) of transmitting to hardware.
  • each step may be performed by the above-described vehicle virtualization structure-based sound control device.
  • first sound client and the second sound client are mounted on different virtual engines
  • the first sound client is mounted on a cluster operating system
  • the second sound client is an AVN (Audio Video Navigation) operating system
  • AVN Audio Video Navigation
  • co-driver It can be installed in the Co-Driver operating system
  • RSE Rear Seat Entertainment
  • the priority of the first sound output information may be higher than the priority of the second sound output information.
  • the second sound output information may be output after outputting the first sound output information ( S550 ).
  • a notification (first sound output information) of the driving unit may be output first until a specific time ta
  • audio (second sound output information) of the infotainment unit may be output after a specific time ta.
  • notification sounds such as fuel shortage notification and consumable replacement notification may be preferentially output (played) before media playback such as AVN radio.
  • at least one of the first sound output information and the second sound output information (the second sound output information is transmitted after the first sound output information is transmitted while the vehicle is driving) may be transmitted in response to the comparison result.
  • the level of the output information may include a first level and a second level lower than the first level.
  • the level of the first sound output information may be determined whether the level of the first sound output information is the first level. If the level of the first sound output information is the first level, only the first sound output information may be output and the output of the second sound output information may be blocked ( S580 ).
  • the audio (or sound) of the driving unit may be output while the vehicle is driving and the audio of the infotainment unit may be muted.
  • the driver is fully aware of the dangerous state, so that the occurrence of an accident can be suppressed. That is, as shown in FIG. 18 , only the first sound output information may be output and the output of the second sound output information may be blocked.
  • first sound output information since the vehicle driving unit failure, drowsiness prevention warning sound, etc. (first sound output information) must be output while the infotainment unit audio (second sound output information) is blocked while driving, only the first sound output information is transmitted to the hardware.
  • the level of the first sound output information is the second level
  • the first sound output information and the second sound output information are output for a first time (S590)
  • the second sound output information is continuously output for the first time. It can be output for 2 hours (S595).
  • the first sound output information and the second sound output information may be output until the first time t1.
  • the size AM1 of the first sound output information may be greater than the size AM2 of the second sound output information during the first time t1. Accordingly, the driver can easily recognize the audio of the first sound output information.
  • the first sound output information requesting instantaneous attention such as a lane departure warning sound and a consumable replacement notification while driving, may be easily provided to the driver.
  • the second sound output information may be transmitted to the hardware in the transmitting step.
  • a priority may exist between these devices.
  • AVN Video
  • RSE Radio Service Set
  • Co-drive the order of priority may be set.
  • all sound devices (hereinafter referred to as speakers) of the vehicle may output the corresponding audio.
  • speakers all sound devices (hereinafter referred to as speakers) of the vehicle may output the corresponding audio.
  • AVN and RSE simultaneously output audio when audio is output on the front of the vehicle, the audio output of AVN is output from the speaker on the front of the vehicle, and audio output of RSE is output from the speaker on the rear of the vehicle can be Also, when the AVN and the co-drive simultaneously output audio, the most recently output audio output among the AVN and the co-drive may be output to all speakers of the vehicle.
  • 20 is a conceptual diagram of a system based on a vehicle virtualization structure according to a modification.
  • the vehicle virtualization structure-based system includes at least hardware (not shown), the base operating system 10 mounted on the hardware (not shown), and at least the base operating system 10 mounted on the base operating system 10 .
  • the plurality of applications 50a to 50d, the plurality of operating system platforms 40a to 40f, or the plurality of displays 60a to 60f and virtual engines 20a to 20b for outputting a plurality of applications, etc., the plurality of operating systems 30a to 30d) may include a container management unit (CM) for managing the environment.
  • CM container management unit
  • At least one operating system will be described below as a 'container'. That is, the above-described sound control may be performed with the system based on the vehicle virtualization structure shown in FIG. 20 without the above-described virtual engine.
  • Computer-readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media.
  • Computer-readable media may include computer storage media.
  • Computer storage media may include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • vehicle software control device described in this embodiment may be implemented as a computer program stored in a computer-implementable storage medium.
  • ' ⁇ unit' used in this embodiment means software or hardware components such as field-programmable gate array (FPGA) or ASIC, and ' ⁇ unit' may perform certain roles.
  • '-part' is not limited to software or hardware.
  • ' ⁇ ' may be configured to reside on an addressable storage medium or may be configured to refresh one or more processors. Accordingly, as an example, ' ⁇ ' indicates components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, and procedures.
  • components and ' ⁇ units' may be combined into a smaller number of components and ' ⁇ units' or further separated into additional components and ' ⁇ units'.
  • components and ' ⁇ units' may be implemented to play one or more CPUs in a device or secure multimedia card.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

실시예는 복수의 컨테이너를 부팅하는 단계; 상기 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계; 및 상기 업그레이드의 필요성에 대응하여 상기 복수의 컨테이너에 대한 업그레이드를 수행하는 단계;를 포함하고, 상기 복수의 컨테이너는 시스템 초기화 및 관리를 공유하는 차량 가상화 구조 기반의 제어 방법을 개시한다.

Description

차량 가상화 구조 기반의 시스템 제어 방법 및 장치
본 발명은 실시예는 차량 가상화 구조 기반의 시스템 제어 방법 및 장치에 관한 것이다.
차량은 보다 높은 수준의 전산화로 점차 이동하고 있다. 대부분의 차량 작업, 기능 및 작업은 현재 컴퓨터 제어 중이거나 전산 장치로 모니터링될 수 있다. 다시 말해, 디지털 시대가 도래함에 따라 소비자들은 휴대폰과 테블릿 컴퓨터 사이와 유사한 수행을 차량 내에서도 수행할 수 있다. 예컨대, 터치 및 햅틱 피드백, 자연 언어 음성 상호 작용, 근접 감지 및 버튼 및 컨트롤을 갖춘 지능형 사용자 인터페이스가 있는 차량용 인포테인먼트 시스템이 현재 각광받고 있다. 이에, 차량 내의 정보, 통신 내비게이션, 동시에 엔터테인먼트를 간소화하고 운전 사용에 맞게 조정하고 있다.
이러한 기술 상황에 맞춰, 차량 내에는 복수의 디스플레이 장치가 존재하며, 디스플레이 장치를 실행하는 소프트웨어도 다수 존재한다. 또한, 차량 에서 사용자 또는 탑승자는 복수의 디스플레이 장치에 사용 자유도가 향상되고 있다.
다만, 차량 내에서 운영체제 간의 업데이트가 어렵고, 웹 플랫폼 컨테이너 사용이 사용자 별 독립적이지 못한 한계가 존재한다.
나아가, 차량 내에서 사용자 간 음향이 섞여 주행의 위험도가 증가해지는 문제점이 있다.
실시예는 디스크 자원 절약이 가능한 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 제공할 수 있다.
또한, 구동 속도가 개선된 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 제공할 수 있다.
또한, 차량 내 사용자 맞춤형 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 제공할 수 있다.
또한, 차량 내 사용자 별 웹 어플리케이션을 용이하게 사용하는 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 제공할 수 있다.
또한, 주행 방해가 제거된 차량 내 음향 처리가 이루어지는 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 제공할 수 있다.
실시예에서 해결하고자 하는 과제는 이에 한정되는 것은 아니며, 아래에서 설명하는 과제의 해결수단이나 실시 형태로부터 파악될 수 있는 목적이나 효과도 포함될 수 있다고 할 것이다.
실시예에 따른 차량 가상화 구조 기반의 제어 방법은 복수의 컨테이너를 부팅하는 단계; 상기 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계; 및 상기 업그레이드의 필요성에 대응하여 상기 복수의 컨테이너에 대한 업그레이드를 수행하는 단계;를 포함하고, 상기 복수의 컨테이너는 시스템 초기화 및 관리를 공유한다.
상기 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계는, 업그레이드 정보를 수신하는 단계; 상기 업그레이드 정보와 상기 복수의 컨테이너의 업그레이드를 비교하는 단계; 및 상기 업그레이드의 필요성을 결정하는 단계;를 포함할 수 있다.
상기 업그레이드의 필요성이 없는 경우에 상기 복수의 컨테이너를 구동하는 단계;를 더 포함할 수 있다.
상기 업그레이드의 필요성이 존재하는 경우에 시스템 디렉터리에 대한 업그레이드 또는 사용자 데이터(personal data)에 대한 업그레이드인지 판단하는 단계;를 더 포함할 수 있다.
상기 시스템 디렉터리에 대한 업그레이드인 경우, 업그레이드인지 판단하는 단계 이후에, 사용자 인증을 수행하는 단계; 및 상기 시스템 디렉터리를 수신하는 단계;를 더 포함할 수 있다.
상기 복수의 컨테이너를 재부팅하는 단계;를 더 포함하고, 상기 업그레이드의 필요성을 확인하는 단계로 돌아갈 수 있다.
상기 사용자 데이터에 대한 업그레이드인 경우 업그레이드인지 판단하는 단계 이후에, 최신의 사용자 데이터를 수신하는 단계; 및 상기 복수의 컨테이너를 구동하는 단계;를 더 포함할 수 있다.
상기 복수의 컨테이너를 구동하는 단계 이후에, 상기 컨테이너와 연결된 디스플레이로 어플리케이션을 실행하는 단계;를 더 포함할 수 있다.
상기 복수의 컨테이너를 구동하는 단계에서, 상기 사용자 데이터 중 변경 디렉토리 카피하여 상기 복수의 컨테이너를 구동할 수 있다.
상기 공유된 시스템 초기화 및 관리는 커널(kernel), 디스트로(distro) 및 라이브러리(library)를 포함할 수 있다.
나아가, 실시예에 따른 차량 가상화 구조 기반의 제어 방법은 상술한 업데이트 등 이후에 컨테이너를 구동함에 있어서, 사용자를 인식하는 단계; 인식된 사용자가 기등록된 사용자인지 확인하는 단계;를 포함한다.
인식된 사용자가 상기 기등록된 사용자가 아닌 경우 등록 진행하는 단계;를 더 포함할 수 있다.
인식된 사용자가 상기 기등록된 사용자인 경우 차량 환경을 설정하는 단계; 웹 계정의 등록 여부 확인하는 단계;를 더 포함할 수 있다.
상기 웹 계정의 등록이 없는 경우 웹 계정 등록하는 단계;를 더 포함할 수 있다.
상기 웹 계정의 등록이 있는 경우 상기 웹 계정이 다른 웹 플랫폼 컨테이너에 로그인된 상황인지 판단하는 단계;를 더 포함할 수 있다.
상기 웹 계정이 다른 웹 플랫폼 컨테이너에 로그인된 경우, 종료 또는 재로그인을 출력하는 단계;를 더 포함할 수 있다.
상기 웹 계정이 다른 웹 플랫폼 컨테이너에 로그인되지 않은 경우 선호 어플리케이션 추출하는 단계; ;를 더 포함할 수 있다.
네비게이션 구동하여 즐겨 찾는 목적지 표시하는 단계;를 더 포함할 수 있다.
실시예에 따른 차량 가상화 구조 기반의 사운드 제어 방법은 제1 사운드 클라이언트로부터 제1 사운드 출력정보 및 제2 사운드 클라이언트로부터 제2 사운드 출력정보 중 적어도 하나를 수신하는 단계; 수신된 상기 제1 사운드 출력정보 및 상기 제2 사운드 출력정보에 대한 우선순위를 비교하는 단계; 및 비교 결과에 대응하여 제1 사운드 출력정보 및 제2 사운드 출력정보 중 적어도 하나를 하드웨어로 송신하는 단계;를 포함하고, 상기 제1 사운드 클라이언트 및 상기 제2 사운드 클라이언트는 서로 다른 가상엔진 상에 탑재된다.
상기 제1 사운드 클라이언트는 클러스터 운영체제에 탑재되고, 상기 제2 사운드 클라이언트는 AVN(Audio Video Navigation) 운영체제, 코-드라이버(Co-Driver) 운영체제, RSE(Rear Seat Entertainment) 운영체제에 탑재될 수 있다.
상기 제1 사운드 출력정보의 우선순위는 상기 제2 사운드 출력정보의 우선순위보다 높을 수 있다.
상기 우선순위를 비교하는 단계 이후에, 상기 제1 사운드 출력정보의 발생 시점이 차량의 주행중인지 여부 확인하는 단계;를 더 포함할 수 있다.
상기 제1 사운드 출력정보의 발생 시점이 차량의 주행중이 아니라면 상기 제1 사운드 출력정보를 출력한 후 상기 제2 사운드 출력정보를 출력하는 단계;를 더 포함할 수 있다.
상기 제1 사운드 출력정보의 발생 시점이 차량의 주행중이라면 상기 제1 사운드 출력정보의 레벨에 따라 상기 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력 여부 및 출력 시간을 조절하여 출력하는 단계;를 포함할 수 있다.
상기 출력정보의 레벨은 제1 레벨 및 상기 제1 레벨보다 낮은 제2 레벨을 포함하고, 상기 제1 사운드 출력정보의 레벨이 제1 레벨이면 상기 제1 사운드 출력정보만 출력하고, 상기 제2 사운드 출력정보의 출력을 차단하는 단계;를 더 포함할 수 있다.
상기 제1 사운드 출력정보의 레벨이 제2 레벨이면, 상기 제1 사운드 출력정보 및 상기 제2 사운드 출력정보를 제1 시간 동안 출력하는 단계; 및 상기 제2 사운드 출력정보를 제1 시간에 연속하는 제2 시간 동안 출력하는 단계;를 포함하고, 상기 제1 시간 동안 상기 제1 사운드 출력정보의 크기는 상기 제2 사운드 출력정보의 크기보다 클 수 있다.
상기 제2 사운드 출력정보만을 수신하면 상기 송신하는 단계에서 상기 제2 사운드 출력정보를 상기 하드웨어로 송신할 수 있다.
실시예에 따른 차량 가상화 구조 기반의 사운드 제어 장치는 제1 사운드 클라이언트로부터 제1 사운드 출력정보 및 제2 사운드 클라이언트로부터 제2 사운드 출력정보 중 적어도 하나를 수신하는 수신부; 수신된 상기 제1 사운드 출력정보 및 상기 제2 사운드 출력정보에 대한 우선순위를 비교하는 비교부; 및 비교 결과에 대응하여 제1 사운드 출력정보 및 제2 사운드 출력정보 중 적어도 하나를 하드웨어로 송신부;를 포함하고, 상기 제1 사운드 클라이언트 및 상기 제2 사운드 클라이언트는 서로 다른 가상엔진 상에 탑재된다.
실시예에 따르면, 디스크 자원 절약이 가능한 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 구현할 수 있다.
또한, 구동 속도가 개선된 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 구현할 수 있다.
또한, 차량 내 사용자 맞춤형 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 구현할 수 있다.
또한, 차량 내 사용자 별 웹 어플리케이션을 용이하게 사용하는 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 구현할 수 있다.
또한, 주행 방해가 제거된 차량 내 음향 처리가 이루어지는 차량 가상화 구조 기반의 시스템 제어 방법 및 장치를 구현할 수 있다.
본 발명의 다양하면서도 유익한 장점과 효과는 상술한 내용에 한정되지 않으며, 본 발명의 구체적인 실시형태를 설명하는 과정에서 보다 쉽게 이해될 수 있을 것이다.
도 1은 실시예에 따른 차량 가상화 구조 기반의 시스템의 개념도이고,
도 2는 실시예에 따른 차량 가상화 구조 기반의 시스템의 구체적인 블록도이고,
도 3은 실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법에 대한 순서도이고,
도 4는 실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법에서 업그레이드의 필요성 확인에 대한 구체적인 순서도이고,
도 5는 실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법에 대한 구체적인 순서도이고,
도 6은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너의 구조에 대한 개념도이고,
도 7 및 도 8은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너를 구동을 설명하는 도면이고,
도 9는 도 2에서 K부분의 확대도이고,
도 10은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 웹 플랫폼 제어 방법에 대한 순서도이고,
도 11은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 웹 플랫폼 제어 방법에서 웹 어플리케이션의 구동을 도시한 도면이고,
도 12는 다른 실시예에 따른 차량 가상화 구조 기반의 시스템의 개념도이고,
도 13은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 디스플레이 장치를 설명하는 도면이고,
도 14는 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 장치의 블록도이고,
도 15는 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 방법의 순서도이고,
도 16은 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 방법의 구체화된 순서도이고,
도 17은 일예에 대한 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력을 설명하는 도면이고,
도 18은 다른예에 대한 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력을 설명하는 도면이고,
도 19는 또 다른예에 대한 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력을 설명하는 도면이고,
도 20은 변형예에 따른 차량 가상화 구조 기반의 시스템의 개념도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제2, 제1 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 구성요소들은 용어들에 의해 한정되지는 않는다. 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제2 구성요소는 제1 구성요소로 명명될 수 있고, 유사하게 제1 구성요소도 제2 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 첨부된 도면을 참조하여 실시예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 대응하는 구성 요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다.
본 개시의 실시예는 차량, 차량 인포테인먼트 등을 위한 차량 스트리밍 제어 장치 및 제어 방법에 관한 것으로, 애플리케이션(동일한 의미로 '앱', '어플리케이션', application) 등을 차량에서 이용함에 있어서, 차량 인포테인먼트와 접목한 시스템 환경을 제공하는 것을 내용으로 한다. 다만, 이러한 내용이 본 특허의 권리를 한정하는 것은 아니다.
보다 상세히 서술하면, 차량용 시스템의 경우 차량용 인포테인먼트 기능을 제공하는 것과 동시에 차량의 제어에 관련된 중요한 기능을 수행하고 있다. 여기서 차량의 제어에 관련된 기능이라 함은 사용자의 차량 조작에 영향을 주는 네 비게이션 시스템 등을 포함하는 애플리케이션부터 차량의 속도나 RPM 등을 표시하는 계기 판을 뜻하는 클러스터 시스템, 자율제어 차량의 자율제어 시스템과 같이 탑승자의 생명에 관련된 중요한 기능까지도 포함한다. 그리고 이러한 애플리케이션의 디스플레이는 자유롭게 이루어지되, 차량 제어 등 주행에 방해가 발생하면 안된다. 즉, 차량 주행에 대한 보호는 필수적으로 지켜져야 한다. 이러한 보호가 이루어지지 않을 경우, 사고가 발생할 수도 있다. 따라서, 본 발명의 바람직한 실시예에서는 주행을 방해하지 않는 범위 내에서 차량 내의 스트리밍이 수행되어, 오디오 재생, 비디오 재생, 게임 실행 등과 같이 엔터테인먼트에 관련된 서비스, 애플리케이션이 운전자를 포함한 차량의 탑승자에 대한 접근 및 조작이 용이하게 이루어질 수 있다.
도 1은 실시예에 따른 차량 가상화 구조 기반의 시스템의 개념도이고, 도 2는 실시예에 따른 차량 가상화 구조 기반의 시스템의 구체적인 블록도이다.
도 1 및 도 2를 참조하면, 실시예에 따른 차량 가상화 구조 기반의 시스템은 하드웨어(미도시됨), 하드웨어(미도시됨) 상에 탑재된 베이스 운영 체제(10), 베이스 운영 체제(10) 상에 탑재된 제1 가상엔진(20a)과 제2 가상엔진(20b), 각 가상엔진 상에 탑재되는 적어도 하나의 운영체제(30a 내지 30f), 적어도 하나의 운영체제(30a 내지 30f) 상에 탑재되고 미들웨어 및 중요 애플리케이션이 포함된 소프트웨어 집합으로 복수의 운영체제 플랫폼(40a 내지 40f), 운영체제 플랫폼(40a 내지 40f)에서 구동되는 복수의 애플리케이션(50a 내지 50d), 복수의 운영체제 플랫폼(40a 내지 40f) 또는 복수의 애플리케이션 등을 출력하는 복수의 디스플레이(60a 내지 60f) 및 가상엔진(20a 내지 20b) 상에서 복수의 운영체제(30a 내지 30d)에 대한 환경을 관리하는 컨테이너 관리부(CM)를 포함할 수 있다. 적어도 하나의 운영체제는 이하 '컨테이너(container)'로 설명한다.
여기서, 하드웨어(미도시됨)는 프로세서, 표시부, 저장부, 메모리부, 컨트롤부, I/O 장치를 포함하는 개념일 수 있다.
실시예에서, 주행부(CP)는 제1 가상엔진(20a) 상에서 탑재 또는 구동되는 시스템 영역이고, 인포테인먼트부(IP, Infotainment Platform)는 제1 가상엔진(20a)과 이종의 가상엔진인 제2 가상엔진(20b) 상에서 탑재 또는 구동되는 시스템 영역일 수 있다. 이러한 구성에 의하여, 인포테인먼트부(IP) 내에서 업그레이드 또는 기타 오작동이 발생하더라도, 주행부(CP)는 이에 대한 영향을 받지 않을 수 있다. 즉, 주행 중 영향이 최소화될 수 있다. 나아가, 인포테인먼트부(IP) 이외에 웹 플랫폼부(Web Platform)이 베이스 운영 체제(10) 및 추가 가상 엔진(20) 상에서 탑재 또는 구동될 수 잇다. 인포테인먼트부(IP)와 마찬가지로 플랫폼부(Web Platform)는 컨테이너 관리자를 인포테인먼트부(IP)와 공유할 수 있다. 또는 플랫폼부(Web Platform)는 인포테인먼트부(IP)의 일부로 구성될 수 있다. 이하에서는 개별적인 구성으로 설명한다.
플랫폼부(Web Platform)는 인포테인먼트부(IP)와 같이 컨테이너 관리부에 탑재된 하나의 운영체제(예로, 컨테이너, 30), 운영체제 상에 탑재되고 미들웨어 및 중요 애플리케이션이 포함된 소프트웨어 집합으로 복수의 운영체제 플랫폼(예로, AGL, 40), 운영체제 플랫폼(40)에서 구동되는 복수의 애플리케이션(예로, 웹어플리케이션, 50)을 포함할 수 있다.
먼저, 베이스 운영 체제(10)는 예를 들어 다양한 운영체제일 수 있다. 예컨대, 베이스 운영 체제(10)는 리눅스(linux), 하이퍼바이저(hypervisor), QNX, GENIVI 등을 포함할 수 있다.
예를 들어, 제1 가상엔진(20a)과 제2 가상엔진(20b)은 미들웨어 솔루션 또는 다양한 플랫폼으로서,　모바일　C 언어로 개발될 수 있다. 제1 가상엔진(20a)과 제2 가상엔진(20b)은 다수의 내장 라이브러리를 제공할 수 있으며, 다양한 이동 단말기 등에서 동일한 동작을 수행할 수도 있다. 예컨대, 제1 가상엔진(20a)과 제2 가상엔진(20b)은 리눅스 기반의 안드로이드 커널일 수 있으며, 메모리 보호, 가상 메모리 모듈 및 스케줄 캐싱을 초기화할 수도 있다.
또한, 적어도 하나의 컨테이너(30a 내지 30d)는 제2 가상엔진(20a) 상에 탑재되고 제1 가상엔진(10a) 상에 탑재되지 않을 수 있다. 이에, 주행부(CP)에 대한 보안성이 향상되므로, 주행 안정성도 개선될 수 있다.
적어도 하나의 컨테이너(30a 내지 30d)는 실시예로 가상화 방식의 일 형태로서 프로세스 가상화의 일정일 수 있다. 예컨대, 컨테이너를 이용한 가상화 기술은 호스트 OS(operating system) 내부를 물리적 자원을 관리하는 커널 공간과 사용자 프로세스, 즉 응용 프로그램(어플레케이션, application, APP)을 실행하는 사용자 공간으로 구분하고 사용자 공간을 여러 개로 나누어 각각의 사용자 프로세스에서 사용되는 하드웨어 자원을 할당하고 공유하는 기술을 의미할 수 있다. 예컨대, 컨테이너(30a 내지 30d)는 호출된 라이브러리를 시스템 라이브러리와 인터페이스되도록 변환하여, 베이스 운영체제와 복수의 운영체제 플랫폼 간의 연결 또는 호환을 수행할 수 있다.
복수의 운영체제 플랫폼(40a 내지 40f)은 컨테이너 상에 탑재될 수 있다. 복수의 운영체제 플랫폼(40a 내지 40f)는 안드로이드, AGL(Automotive Grade Linux), 웹 (web)플랫폼, 클러스터(cluster) 플랫폼, 헤드업 디스플레이(HUD) 플랫폼 등을 포함할 수 있다.
적어도 하나의 애플리케이션(50a 내지 50d)은 시스템 프로그램을 제외한 응용 프로그램으로써, 차량 내에서는 AVN(Audio Video Navigation), 코-드라이버(Co-Driver), RSE(Rear Seat Entertainment) 등을 포함할 수 있다.
복수의 디스플레이(60a 내지 60f)는 운영체제 플랫폼(40a 내지 40f) 또는 플랫폼 상의 응용 프로그램 등을 사용자(예로, 탑승자)에게 표시할 수 있다. 예컨대, 복수의 디스플레이(60a 내지 60f)는 다양한 표시 장치(예로, OLED)를 포함할 수 있다.
컨테이너 관리부(CM)는 가상엔진(20a 내지 20b) 상에서 복수의 운영체제(30a 내지 30d)에 대한 환경을 관리할 수 있다. 즉, 컨테이너 관리부(CM)는 복수의 운영체제(30a 내지 30d) 예로, 컨테이너에 대한 자원 할당, 스트리밍 연결, 업데이트, 디스플레이 출력 담당, 출력부와 연결 등을 수행할 수 있다. 이에 대한 자세한 설명은 후술한다.
구체적으로, 컨테이너 관리부(CM)는 컨테이너 제어부(CM1), 컨테이너 업그레이드부(CM2), 컨테이너 상태관리부(CM3), 웹 플랫폼 컨테이너 관리부(CM4), 컨테이너 브리지부(CM5)를 포함할 수 있다.
컨테이너 제어부(CM1)는 컨테이너에 할당되는 시스템 자원, 자원 정책, 스트리밍 제어 관련, 디스플레이로 출력 관련, 파일 시스템 관리 등을 수행할 수 있다.
이러한 컨테이너 제어부(CM1)는 컨테이너 리소스 관리부(M1-1), 디스플레이 제어부(M1-2), 컨테이너 정책 관리부(M1-3), 컨테이너 파일 시스템 관리부(M1-4), 컨테이너 스트리밍 관리부(M1-5) 및 오디오 정책 및 제어 관리부(M1-6)를 포함할 수 있다.
컨테이너 리소스 관리부(M1-1)는 컨테이너에 할당되는 시스템 자원을 동적으로 할당할 수 있다. 예컨대, 컨테이너 리소스 관리부(M1-1)는 자원 사용량을 수집하여 자원 부족으로 인한 QoS 성능저하를 예방할 수 있다. 예를 들어, 컨테이너 리소스 관리부(M1-1)는 기설정된 컨테이너의 우선순위, 자원사용량 임계값 및 모니터링 감시 주기를 이용하여 전용코어에 할당되는 컨테이너를 설정할 수 있다.
컨테이너 정책 관리부(M1-3)는 상술한 컨테이너 중 전용코어에 할당되는 우선순위에 대한 정보를 포함할 수 있다.
디스플레이 제어부(M1-2)는 복수의 디스플레이 각각의 동작을 담당하는 컨테이너 들이 차량 내의 각 디스플레이에 화면을 출력하도록 관리할 수 있다.
컨테이너 파일 시스템 관리부(M1-4)는 복수의 컨테이너 환경에서 각 컨테이너의 동작에 필요한 파일들을 체계적이고 효율적으로 관리할 수 있다. 예컨대, 컨테이너 파일 시스템 관리부(M1-4)는 후술하는 바와 같이 어느 하나의 파일 시스템 예로 컨테이너의 파일 시스템을 다른 하나의 컨테이너 파일 시스템으로 오버레이할 수 있다. 이에, 사용자(복수의 탑승자)는 컨테이너와 같은 파일 시스템을 다른 사용자 또는 다른 위치(예로, 좌석)에서 용이하게 공유할 수 있다.
즉, 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너는 시스템 초기화 및 관리를 공유할 수 있다. 예를 들어, 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너는 rootfs를 공유할 수 있다. 그리고 각 운영체제 즉 컨테이너는 별도 변경 디렉토리를 저장 또는 복사(카피)하여 디스크 등의 자원이 효율적으로 이용될 수 있다. 나아가, 각 컨테이너 별 업그레이드도 변경 디렉토리만을 이용하여 수행될 수 있다. 예를 들어, 각 디스플레이 장치가 효과적으로 업그레이드될 수 있다.
컨테이너 스트리밍 관리부(M1-5)는 각 디스플레이에서 출력되는 영상의 이동 등을 관리할 수 있다. 즉, 컨테이너 스트리밍 관리부(M105)는 주행부와 인포테인먼트부 나아가, 디스플레이 각각의 정책에 따라 스트리밍 가능 여부를 판단할 수 있다.
오디오 정책 및 제어 관리부(M1-6)는 적어도 하나의 컨테이너 간의 오디오 출력에 대한 정책을 반영하여 오디오 출력을 제어할 수 있다. 이에 대한 자세한 설명은 후술한다.
컨테이너 업그레이드부(CM2)는 복수의 운영체제로 이루어진 인포테인먼트부의 각 운영체제 별로 업그레이드를 수행할 수 있다. 예컨대, 컨테이너 업그레이드부(CM2)는 컨테이너로 구성된 인포테인먼트부의 각 컨테이너를 용이하게 업그레이드할 수 있다.
컨테이너 업그레이드부(CM2)는 업데이트 및 확인 관리부(M2-1) 및 인증 관리부(M2-2)를 포함할 수 있다.
업데이트 및 확인 관리부(M2-1)는 복수의 컨테이너 중 업데이트가 필요한 컨테이너를 위한 컨테이너 별 식별자 및 업데이트 후 정상 동작 확인을 수행할 수 있다.
인증 관리부(M2-2)는 업데이트를 수행하기 위해 차량 및 컨테이너 별 인증, 버전 비교를 수행할 수 있다.
컨테이너 상태관리부(CM3)는 컨테이너의 정상 동작 여부에 대한 확인 등 복수의 컨테이너 상태를 관리할 수 있다.
컨테이너 상태관리부(CM3)는 상태 관리부(M3-1), 로그 관리부(M3-2)를 포함할 수 있다.
상태 관리부(M3-1)는 주기적인 모니터링을 통해 컨테이너 및 컨테이너 관리부의 기능이 정상 동작하는지 확인할 수 있다.
로그 관리부(M3-2)는 컨테이너 상태관리부를 통해 확인된 내용을 로그를 보관할 수 있다. 나아가, 로그 관리부(M3-2)는 소정의 시간 후에 로그를 삭제하거나 백업 처리할 수 있다. 나아가, 컨테이너가 비정상 동작하는 경우 로그 관리부(M3-2)를 통해 상태 관리부(M3-1)가 해당 문제를 용이하게 해결할 수 있다.
웹 플랫폼 컨테이너 관리부(CM4)는 웹 플랫폼 컨테이너에 대한 관리를 수행할 수 있으며, 웹 플랫폼 관리부(M4-1), 웹 계정 관리부(M4-2)를 포함할 수 있다.
웹 플랫폼 관리부(M4-1)는 웹 플랫폼의 다양한 기능이 운영체제 즉, 컨테이너 상에서 정상 동작하는지 관리할 수 있다. 그리고 웹 플랫폼 관리부(M4-1)는 복수의 웹 플랫폼 컨테이너가 동작하는 경우 각 컨테이너 별로 로그인 계정을 관리하여 개인화된 웹 이용 환경을 관리할 수 있다. 이에 대한 자세한 설명은 후술한다.
나아가, 컨테이너 브리지부(CM5)는 인터페이스, 하드웨어 등과 연결되어 디스플레이, 오디오, 어플리케이션, 네트워크 등에 대한 각 운영체제 간의 상호 연결을 수행할 수 있다.
그리고 도면에 기재된 각 요소는 예시이며, 이하에서는 이를 기준으로 설명한다.
또한, 사용자(예로, 탑승자)는 사용자 인터페이스 등을 통해 차량 가상화 구조 기반의 시스템을 조작할 수 있다. 그리고 조작 과정 또는 결과가 디스플레이, 오디오 등의 출력 장치를 통해 사용자에게 제공될 수 있다. 또한, 사용자가 디스플레이 터치를 조작하는 등의 입력을 통해, 이에 대한 피드백이 이루어질 수 있다.
도 3은 실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법에 대한 순서도이고, 도 4는 실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법에서 업그레이드의 필요성 확인에 대한 구체적인 순서도이고, 도 5는 실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법에 대한 구체적인 순서도이고, 도 6은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너의 구조에 대한 개념도이고, 도 7 및 도 8은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너를 구동을 설명하는 도면이다.
실시예에 따른 차량 가상화 구조 기반의 시스템 제어 방법은 복수의 컨테이너를 부팅하는 단계(S310), 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계(S320), 및 업그레이드의 필요성에 대응하여 복수의 컨테이너에 대한 업그레이드를 수행하는 단계(S330)를 포함할 수 있다.
이 때, 실시예에 따른 차량 가상화 구조 기반의 시스템에서 복수의 컨테이너는 상술한 바와 같이 시스템 초기화 및 관리를 공유할 수 있다.
예컨대, 복수의 컨테이너(Container1 내지 Container 3)는 공유된 시스템 초기화 및 관리인 rootfs를 공유할 수 있다. 즉, 복수의 컨테이너(Container1 내지 Container 3)는 커널(kernel), 디스트로(distro) 및 라이브러리(library)를 서로 공유할 수 있다.
이 때, 차량 가상화 구조 기반의 시스템 제어 방법은 상술한 컨테이너 관리부(CM)에서 수행될 수 있다. 즉, 차량 가상화 구조 기반의 시스템 제어 장치는 컨테이너 관리부(CM)를 포함할 수 있다. 나아가, 차량 가상화 구조 기반의 시스템 제어 장치는 컨테이너 제어부(CM1), 컨테이너 업그레이드부(CM2)를 포함할 수 있으며, 후술하는 각 제어 단계를 수행할 수 있다. 이하에서 각 단계가 수행되는 장치에 대해서 간략하게 기재한다.
실시예로, 컨테이너 제어부는 복수의 컨테이너를 부팅할 수 있다(S310). 그리고 컨테이너 업그레이드부(CM2)는 운영체제 즉 부팅된 복수의 컨테이너에 대한 업그레이드의 필요성을 판단할 수 있다(S320)
구체적으로, 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계는 업그레이드 정보를 수신하는 단계(S321), 업그레이드 정보와 복수의 컨테이너의 업그레이드를 비교하는 단계(S322), 업그레이드의 필요성을 결정하는 단계(S323)을 포함할 수 있다.
컨테이너 업그레이드부(CM2)는 서버 등으로부터 업데이트 정보를 수신할 수 있다. 업데이트 정보는 해당 컨테이너의 버전 정보를 포함할 수 있다.
그리고 컨테이너 관리부(CM) 또는 컨테이너 업그레이드부(CM2)는 수신한 업그레이드와 복수의 컨테이너의 업그레이드 즉, 업그레이드 정보와 비교할 수 있다. 이에, 수신한 업그레이드 정보와 대응하는 컨테이너의 업그레이드 정보를 비교하여, 컨테이너의 업그레이드 정보가 수신한 업그레이드 정보보다 최신이 아닌지 판단할 수 있다.
예컨대, 컨테이너 관리부(CM) 또는 컨테이너 업그레이드부(CM2)는 수신한 업그레이드 정보와 컨테이너의 업그레이드 정보가 동일한 버전이거나, 컨테이너의 업그레이드 정보가 최신인 경우에 업그레이드의 필요성이 없다고 판단할 수 있다. 또한, 수신한 업그레이드의 정보가 컨테이너의 업그레이드 정보보다 낮은 버전인 경우에 업그레이드의 필요성이 있다고 판단할 수 있다. 즉, 복수의 컨테이너의 업그레이드의 필요성 존재 유무를 판단할 수 있다(S334).
그리고 컨테이너 관리부(CM)는 업그레이드의 필요성에 대응하여 복수의 컨테이너에 대한 업그레이드를 수행할 수 있다(S330). 업그레이드의 필요성이 존재하는 경우에만, 컨테이너 관리부(CM)는 복수의 컨테이너에 대한 업그레이드를 수행할 수 있다. 그리고 업그레이드의 필요성이 존재하지 않는 경우에, 컨테이너 제어부(CM1)는 복수의 컨테이너를 구동할 수 있다(S340). 즉 각 디스플레이 별 사용자 데이터(personal Data)를 로딩하여 컨테이너를 구동할 수 있다. 이 때, 상술한 바와 같이, 컨테이너 관리부(CM) 또는 컨테이너 제어부(CM1)는 차량 내 각 디스플레이별 컨테이너에서 시스템 초기화 및 관리인 rootfs를 공유하며, 각 컨테이너(예로, 디스플레이 별)가 사용자 데이터를 공유된 rootfs에 오버레이하므로 디스크 자원을 절약할 수 있다. 이에, 효율적인 컨테이너 운영 또는 구동이 이루어질 수 있다. 나아가, 컨테이너는 사용자 데이터를 복사하여(copied) 구동될 수 있다. 실시예로, 사용자 데이터 중 변경 디렉토리 카피하여 복수의 컨테이너를 구동 또는 수행할 수 있다. 즉, 최신 버전의 사용자 데이터(delta0/)가 새로운 사용자 데이터(delta1/)로 복사(copied)될 수 있다. 이에, 기존 컨테이너(original)의 구동 이후에 새로운 컨테이너(snap clone)의 구동이 용이하게 이루어질 수 있다. 예컨대, 복수 개의 RSE 디스플레이에 대한 컨테이너는 구동이 보다 용이하게 이루어질 수 있다. 또한, 기존 최신 버전의 사용자 데이터 또는 구동된 사용자 데이터(new files)가 상술한 바와 같이 공유된 rootfs(root files)에 오버레이될 수 있다(mount). 이로써, 컨테이너의 구동 및 업데이트(시스템 파일 및 사용자 데이터)가 모두 용이하게 이루어질 수 있다.
그리고 컨테이너 관리부(CM) 또는 컨테이너 제어부(CM1)는 컨테이너와 연결된 디스플레이로 어플리케이션을 실행할 수 있다(S350). 이에, 차량 내 각 탑승자에 위치한 디스플레이 별 각 서비스(예로, 어플리케이션 실행)가 탑승자에게 제공될 수 있다.
그리고 컨테이너 관리부(CM) 또는 컨테이너 제어부(CM1)는 업그레이드의 필요성이 존재하는 경우에 시스템 디렉터리에 대한 업그레이드 또는 사용자 데이터(personal data)에 대한 업그레이드인지 판단할 수 있다(S360). 이는 상술한 업그레이드의 필요성에 대응하여 복수의 컨테이너에 대한 업그레이드를 수행하는 단계(S330)가 구체화되는 단계일 수 있다. 즉, 컨테이너에 대한 업그레이드의 수행이 이하와 같이 구체화되어 이루어질 수 있다.
시스템 디렉터리에 대한 업그레이드인 경우, 컨테이너 관리부(CM)는 업그레이드인지 판단한(S360) 이후에, 사용자 인증을 수행하고(S370), 시스템 디렉터리를 수신할 수 있다(S380).
컨테이너 관리부(CM) 또는 컨테이너 업그레이드부(CM2)는 사용자 인증을 수행할 수 있다. 사용자 인증은 차량 및 컨테이너에 대한 인증을 포함할 수 있다. 즉, 차량의 종류와 컨테이너의 종류를 판단한 뒤, 해당 차량에 대응하는 컨테이너에 대한 인증을 수행할 수 있다(S370).
그리고 컨테이너 관리부(CM) 또는 컨테이너 업그레이드부(CM2)는 서버로부터 최신 버전의 파일 시스템(file system)을 수신할 수 있다. 예컨대, 파일 시스템으로 커널, OS, 라이브러리가 존재한다. 수신된 파일 시스템이 공유된 rootfs에 적용될 수 있다. 즉, 실시예에 따른 차량 가상화 구조 기반의 제어 방법 및 장치는 컨테이너 관리부에 의해(또는 컨테이너 관리부를 포함하여) 동일 가상 엔진 상에 동일 컨테이너 종류에 대한 시스템 디렉터리 업그레이드를 용이하게 수행할 수 잇다. 즉, 1번의 시스템 디렉터리 수신으로 복수의 컨테이너에 대한 시스템 디렉터리 업그레이드가 이루어질 수 있다. 이후에, 복수의 컨테이너를 재부팅할 수 있다(S390).
이후에, 업그레이드의 필요성을 확인하는 단계(S320)으로 돌아가 상술한 단계 또는 기능을 수행할 수 있다.
사용자 데이터(personal data)에 대한 업그레이드인 경우 업그레이드인지 판단하는 단계(S360) 이후에 복수의 컨테이너를 구동할 수 있다(S340). 다만 이전에 최신의 사용자 데이터를 수신(S365)할 수 있다. 여기서, 최신은 보전이 상위이거나 수정된 날짜가 가장 가까운 경우를 의미한다.
최신의 사용자 데이터를 각 컨테이너에 적용할 수 있다. 이 때, 상술한 바와 같이, 공유된 rootfs에 사용자 데이터를 오버레이하여 사용자 데이터를 로딩하고 개별 컨테이너를 구동할 수 있다. 이에, 디스크 자원에 대한 사용을 최소화할 수 있다.
나아가, 컨테이너 관리부(CM)는 컨테이너와 연결된 디스플레이로 어플리케이션을 실행할 수 있다(S350). 즉, 어플리케이션이 각 컨테이너 상에 구동되고 각 디스플레이를 통해 출력될 수 있다. 이에, 차량 내 각 탑승자에 위치한 디스플레이 별 각 서비스(예로, 어플리케이션 실행)가 탑승자에게 제공될 수 있다.
도 9는 도 2에서 K부분의 확대도이고, 도 10은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 웹 플랫폼 제어 방법에 대한 순서도이고, 도 11은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 웹 플랫폼 제어 방법에서 웹 어플리케이션의 구동을 도시한 도면이다.
도 9 내지 도 11을 참조하면, 상술한 바와 같이 실시예에 따른 차량 가상화 구조 기반의 시스템은 베이스 운영 체제(10) 및 추가 가상 엔진(20) 상에서 탑재 또는 구동되는 웹 플랫폼부(Web Platform)을 포함할 수 있다. 인포테인먼트부(IP)와 마찬가지로 플랫폼부(Web Platform)는 컨테이너 관리자를 인포테인먼트부(IP)와 공유할 수 있다. 또는 플랫폼부(Web Platform)는 인포테인먼트부(IP)의 일부로 구성될 수 있다. 이에 대해서는 언급한 바와 같이 개별적인 구성으로 설명한다.
또한, 플랫폼부(Web Platform)는 인포테인먼트부(IP)와 같이 컨테이너 관리부에 탑재된 하나의 운영체제(예로, 컨테이너, 30), 운영체제 상에 탑재되고 미들웨어 및 중요 애플리케이션이 포함된 소프트웨어 집합으로 복수의 운영체제 플랫폼(예로, AGL, 40), 운영체제 플랫폼(40)에서 구동되는 복수의 애플리케이션(예로, 웹어플리케이션, 50)을 포함할 수 있다.
나아가, 가상 엔진(20)에는 차량 정보 서비스 서버(Vehicle Information Service Sever, VIS server)를 포함할 수 있다. 차량 정보 서비스 서버(Vehicle Information Service Sever, VIS server)는 차량 구동부 정보(속도, 연료량 등) 및 차량 설정 정보(온도, 시트위치 등)를 저장하고 각 웹 플랫폼 컨테이너 즉 운영체제 플랫폼(40)에 전송할 수 있다. 즉, 차량 정보 서비스 서버(Vehicle Information Service Sever, VIS server)는 각 웹 운영체제 플랫폼(40) 내의 차량 정보 서비스 클라이언트(Vehicle Information Service Sever, VIS Client)로 요청된 또는 탑승자에 대응한 차량 구동부 정보 및 차량 설정 정보를 제공할 수 있다.
그리고 컨테이너 관리자(CM)는 상술한 바와 같이 웹 플랫폼 컨테이너 관리부(CM4)를 포함할 수 있다. 또한, 웹 플랫폼 컨테이너 관리부(CM4)는 웹 플랫폼 컨테이너에 대한 관리를 수행할 수 있으며, 웹 플랫폼 관리부, 웹 계정 관리부를 포함할 수 있다.
웹 플랫폼 관리부는 웹 플랫폼의 다양한 기능이 운영체제 즉, 컨테이너 상에서 정상 동작하는지 관리할 수 있다. 그리고 웹 플랫폼 관리부는 복수의 웹 플랫폼 컨테이너가 동작하는 경우 각 컨테이너 별로 로그인 계정을 관리하여 개인화된 웹 이용 환경을 관리할 수 있다.
운영체제 플랫폼(40)은 AGL로, 요청된 또는 탑승자에 대응한 차량 구동부 정보 및 차량 설정 정보를 제공받아 차량 환경을 설정하는 서비스 클라이언트(Vehicle Information Service Sever, VIS Client)를 포함할 수 있다.
나아가, 운영체제 플랫폼(40)은 사용자 인식 및 등록을 위한 API 서비스부(Device API service), 운영체제 플랫폼에 포함된 웹 어플리케이션을 관리하는 기능을 확장하기 위해 복수 개의 웹 플랫폼 컨테이너(운영체제, 30)가 구동 시 GPS 등의 하드웨어 자원을 복수의 웹 어플리케이션이 이용할 수 있는지 여부를 모니터링하고 관리하는 애드온부(WAM add on), 및 웹 어플리케이션 이용 시 텍스트 입력이 필요한 경우를 위한 가상키보드부(Virtual Keyboard)를 포함할 수 있다.
보다 구체적으로, 실시예에 따른 차량 가상화 구조 기반의 제어 방법은 웹 플랫폼 제어와 관련하여 사용자를 인식하는 단계(S405), 인식된 사용자가 기등록된 사용자인지 확인하는 단계(S410)를 포함할 수 있다.
즉, 운영체제 플랫폼(40) 또는 API 서비스부(Device API service)는 사용자를 인식할 수 있다(S405). 다시 말해, 차량 내 각 탑승자에 대한 개별적인 인식이 이루어질 수 있다. 이는 다양한 장치(센서, 모바일, 어플리케이션 등)를 통해 사용자 인식이 수행될 수 있다. 또한, 사용자를 인식하는 단계(S405)는 전술한 업데이트 및 컨테이너 구동 이후에 수행될 수 있다. 예를 들어, 사용자를 인식하는 단계(S405)는 어플리케이션이 각 컨테이너 상에서 구동되고 각 디스플레이로 출력된(S350) 이후에 수행될 수 있다. 이 때, 차량 내 탑승자의 사용자가 웹 플랫폼 컨테이너를 구동하고 사용자 인식이 수행될 수 있다.
운영체제 플랫폼(40) 또는 API 서비스부(Device API service)는 인식된 사용자가 기등록된 사용자인지 확인할 수 있다(S410). 운영체제 플랫폼(40) 또는 API 서비스부(Device API service)는 기존에 등록된 사용자가 아닌 경우에 사용자 등록을 진행하고(S415), 기존에 등록된 사용자인 경우에 차량 환경을 설정할 수 있다(S420). 환경은 시트 포지션, 선호 온도, 조명광 상태 등을 포함할 수 있다.
특히, 사용자 인식은 컨테이너 관리부(CM) 증 웹 플랫폼 컨테이너 관리부(CM4)과 연계하여 이루어질 수 있다. 웹 플랫폼 컨테이너 관리부(CM4)는 웹 계정 등록, 변경, 삭제 등을 관리하고, 웹 계정이 등록된 계정인 확인할 수 있으며, 웹 계정 별 어플리케이션 리스트 실행 및 관리를 수행하거나, 웹 계정 로그인이 중복으로 일어나지 않도록 로그인 상태를 관리할 수 있다. 즉, 운영체제 플랫폼(40) 또는 API 서비스부(Device API service)으로부터 제공된 사용자 정보가 컨테이너 관리부(CM)에서 확인되고 계정 별 어플리케이션 리스트 실행 및 관리나 중복 로그인 관리가 이루어질 수 있다.
그리고 컨테이너 관리부(CM) 증 웹 플랫폼 컨테이너 관리부(CM4)는 인식된 사용자 즉, 사용자 정보에 대한 웹 계정 등록 여부를 확인할 수 있다(S425).
이에, 컨테이너 관리부(CM) 증 웹 플랫폼 컨테이너 관리부(CM4)는 해당 사용자에 대한 웹 계정이 등록되지 않았거나 없는 경우 웹 계정을 등록하고(S430) 저장하며, 웹 계정이 등록된 경우에 웹 계정이 다른 웹 플랫폼 컨테이너에 로그인되었는지 확인할 수 있다(S435).
이에, 컨테이너 관리부(CM) 증 웹 플랫폼 컨테이너 관리부(CM4)는 웹 계정이 다른 웹 플랫폼 컨테이너에 로그인된 경우 종료 또는 재로그인을 출력하나(S440), 해당 웹 계정이 로그인된 상태가 아니라면 웹 계정 별 어플리케이션을 추출(S445)할 수 있다. 그리고 추출된 웹 계정 별 선호 어플리케이션을 사용자에게 제공할 수 있다(도 11 참조). 이에, 사용자는 웹 계정 별 선호하는 또는 실시간 웹 어플리케이션의 구동에 대해 용이하게 인식할 수 있다.
그리고 컨테이너 관리부(CM) 증 웹 플랫폼 컨테이너 관리부(CM4)는 네비게이션 어플리케이션을 구동하고 목적지를 디스플레이에 표시할 수 있다(S450). 그리고 사용자는 가상키보드부(Virtual Keyboard)를 통해 목적지 입력할 수 있다(S455). 이와 같이, 실시예에 따른 차량 가상화 구조 기반의 제어 방법 및 장치에서 웹 플랫폼 제어로(방법 또는 장치), 사용자 인식에 따라 웹 플랫폼 어플리케이션을 용이하게 사용하며, 각 운영체제(웹 플랫폼 컨테이너)에 동일 어플리케이션을 상이한 사용자 또는 탑승자 웹 계정으로 구동할 수 있다. 이로써, 차량 내 탑승자 간의 개별 계정을 이용하여 동일 어플리케이션을 구동 및 실행할 수 있다.
도 12는 다른 실시예에 따른 차량 가상화 구조 기반의 시스템의 개념도이고, 도 13은 실시예에 따른 차량 가상화 구조 기반의 시스템에서 디스플레이 장치를 설명하는 도면이다.
도 12 및 도 13을 참조하면, 상술한 바와 같이 실시예에 따른 차량 가상화 구조 기반의 시스템은 하드웨어(미도시됨), 하드웨어(미도시됨) 상에 탑재된 베이스 운영 체제(10), 베이스 운영 체제(10) 상에 탑재된 제1 가상엔진(20a)과 제2 가상엔진(20b), 각 가상엔진 상에 탑재되는 적어도 하나의 운영체제(30a 내지 30f), 적어도 하나의 운영체제(30a 내지 30f) 상에 탑재되고 미들웨어 및 중요 애플리케이션이 포함된 소프트웨어 집합으로 복수의 운영체제 플랫폼(40a 내지 40f), 운영체제 플랫폼(40a 내지 40f)에서 구동되는 복수의 애플리케이션(50a 내지 50d), 복수의 운영체제 플랫폼(40a 내지 40f) 또는 복수의 애플리케이션 등을 출력하는 복수의 디스플레이(60a 내지 60f) 및 가상엔진(20a 내지 20b) 상에서 복수의 운영체제(30a 내지 30d)에 대한 환경을 관리하는 컨테이너 관리부(CM)를 포함할 수 있다. 적어도 하나의 운영체제는 이하 '컨테이너(container)'로 설명한다.
여기서, 하드웨어(미도시됨)는 프로세서, 표시부, 저장부, 메모리부, 컨트롤부, I/O 장치를 포함하는 개념일 수 있다.
실시예에서, 주행부(CP)는 제1 가상엔진(20a) 상에서 탑재 또는 구동되는 시스템 영역이고, 인포테인먼트부(IP, Infotainment Platform)는 제1 가상엔진(20a)과 이종의 가상엔진인 제2 가상엔진(20b) 상에서 탑재 또는 구동되는 시스템 영역일 수 있다. 이러한 구성에 의하여, 인포테인먼트부(IP) 내에서 업그레이드 또는 기타 오작동이 발생하더라도, 주행부(CP)는 이에 대한 영향을 받지 않을 수 있다. 즉, 주행 중 영향이 최소화될 수 있다. 나아가, 인포테인먼트부(IP) 이외에 웹 플랫폼부(Web Platform)이 베이스 운영 체제(10) 및 추가 가상 엔진(20) 상에서 탑재 또는 구동될 수 잇다. 인포테인먼트부(IP)와 마찬가지로 플랫폼부(Web Platform)는 컨테이너 관리자를 인포테인먼트부(IP)와 공유할 수 있다. 또는 플랫폼부(Web Platform)는 인포테인먼트부(IP)의 일부로 구성될 수 있다. 이하에서는 개별적인 구성으로 설명한다.
플랫폼부(Web Platform)는 인포테인먼트부(IP)와 같이 컨테이너 관리부에 탑재된 하나의 운영체제(예로, 컨테이너, 30), 운영체제 상에 탑재되고 미들웨어 및 중요 애플리케이션이 포함된 소프트웨어 집합으로 복수의 운영체제 플랫폼(예로, AGL, 40), 운영체제 플랫폼(40)에서 구동되는 복수의 애플리케이션(예로, 웹어플리케이션, 50)을 포함할 수 있다.
먼저, 베이스 운영 체제(10)는 예를 들어 다양한 운영체제일 수 있다. 예컨대, 베이스 운영 체제(10)는 리눅스(linux), 하이퍼바이저(hypervisor), QNX, GENIVI 등을 포함할 수 있다.
예를 들어, 제1 가상엔진(20a)과 제2 가상엔진(20b)은 미들웨어 솔루션 또는 다양한 플랫폼으로서,　모바일　C 언어로 개발될 수 있다. 제1 가상엔진(20a)과 제2 가상엔진(20b)은 다수의 내장 라이브러리를 제공할 수 있으며, 다양한 이동 단말기 등에서 동일한 동작을 수행할 수도 있다. 예컨대, 제1 가상엔진(20a)과 제2 가상엔진(20b)은 리눅스 기반의 안드로이드 커널일 수 있으며, 메모리 보호, 가상 메모리 모듈 및 스케줄 캐싱을 초기화할 수도 있다.
또한, 적어도 하나의 컨테이너(30a 내지 30d)는 제2 가상엔진(20a) 상에 탑재되고 제1 가상엔진(10a) 상에 탑재되지 않을 수 있다. 이에, 주행부(CP)에 대한 보안성이 향상되므로, 주행 안정성도 개선될 수 있다.
적어도 하나의 컨테이너(30a 내지 30d)는 실시예로 가상화 방식의 일 형태로서 프로세스 가상화의 일정일 수 있다. 예컨대, 컨테이너를 이용한 가상화 기술은 호스트 OS(operating system) 내부를 물리적 자원을 관리하는 커널 공간과 사용자 프로세스, 즉 응용 프로그램(어플레케이션, application, APP)을 실행하는 사용자 공간으로 구분하고 사용자 공간을 여러 개로 나누어 각각의 사용자 프로세스에서 사용되는 하드웨어 자원을 할당하고 공유하는 기술을 의미할 수 있다. 예컨대, 컨테이너(30a 내지 30d)는 호출된 라이브러리를 시스템 라이브러리와 인터페이스되도록 변환하여, 베이스 운영체제와 복수의 운영체제 플랫폼 간의 연결 또는 호환을 수행할 수 있다.
복수의 운영체제 플랫폼(40a 내지 40f)은 컨테이너 상에 탑재될 수 있다. 복수의 운영체제 플랫폼(40a 내지 40f)는 안드로이드, AGL(Automotive Grade Linux), 웹 (web)플랫폼, 클러스터(cluster) 플랫폼, 헤드업 디스플레이(HUD) 플랫폼 등을 포함할 수 있다. 나아가, 운영체제 플랫폼(40) 내에 복수 개의 사운드 클라이언트가 배치될 수 있다. 복수 개의 사운드 클라이언트는 제1 사운드 클라이언트 및 제2 사운드 클라이언트를 포함할 수 있다. 이 때, 제1 사운드 클라이언트는 제1 가상엔진(20a) 상의 운영체제 플랫폼(40a, 40b)에 탑재될 수 있다. 제2 사운드 클라이언트는 제2 가상엔진(20b) 상의 운영체제 플랫폼(40c 등)에 탑재될 수 있다. 즉, 제1 사운드 클라이언트 및 상기 제2 사운드 클라이언트는 서로 다른 가상엔진 상에 탑재될 수 있다. 그리고 제1 사운드 클라이언트는 클러스터 운영체제에 탑재(40a) 또는 HUD 운영체제(40b)에 탑재될 수 있다. 그리고 제2 사운트 클라이언트는 AVN(Audio Video Navigation) 운영체제, 코-드라이버(Co-Driver) 운영체제, RSE(Rear Seat Entertainment) 운영체제에 탑재될 수 있다.
나아가, 사운드 서버는 제1 사운드 클라이언트(SC1) 및 제2 사운드 클라이언트(SC2)로부터 각각 제1 사운드 출력정보 및 제2 사운드 출력정보를 수신할 수 있다. 사운드 서버는 가상엔진(20a, 20b)에 또는 베이스 운영체제(10) 내에 탑재될 수 있다. 이하에서는 사운드 서버는 제1 사운드 서버(SS1), 제2 사운드 서버(SS2)를 포함하고, 제1 사운드 서버(SS1) 및 제2 사운드 서버(SS2)는 이종의 가상엔진에 탑재되는 것을 기준으로 설명한다.
적어도 하나의 애플리케이션(50a 내지 50d)은 시스템 프로그램을 제외한 응용 프로그램으로써, 차량 내에서는 AVN(Audio Video Navigation), 코-드라이버(Co-Driver), RSE(Rear Seat Entertainment) 등을 포함할 수 있다.
복수의 디스플레이(60a 내지 60f)는 운영체제 플랫폼(40a 내지 40f) 또는 플랫폼 상의 응용 프로그램 등을 사용자(예로, 탑승자)에게 표시할 수 있다. 예컨대, 복수의 디스플레이(60a 내지 60f)는 다양한 표시 장치(예로, OLED)를 포함할 수 있다.
이하에 대한 설명은 상술한 오디오 정책 및 제어 관리부에 대한 내용일 수 있다.
또한, 사용자(예로, 탑승자)는 사용자 인터페이스 등을 통해 차량 가상화 구조 기반의 시스템을 조작할 수 있다. 그리고 조작 과정 또는 결과가 디스플레이, 오디오 등의 출력 장치를 통해 사용자에게 제공될 수 있다.
도 14는 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 장치의 블록도이고, 도 15는 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 방법의 순서도이고, 도 16은 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 방법의 구체화된 순서도이고, 도 17은 일예에 대한 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력을 설명하는 도면이고, 도 18은 다른예에 대한 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력을 설명하는 도면이고, 도 19는 또 다른예에 대한 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력을 설명하는 도면이다.
도 14를 참조하면, 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 장치(100)는 수신부(110), 비교부(120), 판단부(130) 및 송신부(140)를 포함할 수 있다. 이 때, 차량 가상화 구조 기반의 사운드 제어 장치(100)는 오디오 정책 및 제어 관리부를 포함하며, 오디오 정책 및 제어 관리부는 수신부(110), 비교부(120), 판단부(130) 및 송신부(140)에 대응할 수 있다.
먼저, 수신부(110)는 각 사운드 클라이언트로부터 사운드 출력정보를 수신할 수 있다. 예컨대, 수신부(110)는 제1 사운드 클라이언트로부터 제1 사운드 출력정보 및 제2 사운드 클라이언트로부터 제2 사운드 출력정보 중 적어도 하나를 수신할 수 있다. 그리고 사운드 출력정보는 사용자의 입력 등에 의해 발생할 수 있다. 즉, 사운드 출력정보는 사용자 입력에 의해 어플리케이션이 수행되면서 출력되는 사운드 정보를 포함할 수 있다.
비교부(120)는 수신된 상기 제1 사운드 출력정보 및 상기 제2 사운드 출력정보에 대한 우선순위를 비교할 수 있다. 제1 사운드 출력정보의 우선순위는 상기 제2 사운드 출력정보의 우선순위보다 높을 수 있다. 이에, 주행부로부터 수신한 사운드 출력 정보가 인포테인먼트부로부터 수신한 사운드 출력 정보보다 우선순위가 높으므로, 주행에 대한 안정성을 향상시킬 수 있다.
판단부(130)는 상기 제1 사운드 출력정보의 발생 시점이 차량의 주행중인지 여부를 판단할 수 있다. 이 때, 판단부(130)는 제1 사운드 출력정보를 출력한 후 제2 사운드 출력정보를 출력하도록 판단할 수 있다.
그리고 판단부(130)는 제1 사운드 출력정보의 발생 시점이 차량의 주행중이라면 제1 사운드 출력정보의 레벨에 따라 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력 여부 및 출력 시간을 조절하여 출력하도록 판단할 수 있다.
구체적으로, 판단부(130)는 제1 사운드 출력정보의 레벨이 제1 레벨이면 상기 제1 사운드 출력정보만 출력하고, 상기 제2 사운드 출력정보의 출력을 차단하도록 판단할 수 있다. 이 때, 출력정보의 레벨은 제1 레벨 및 상기 제1 레벨보다 낮은 제2 레벨을 포함할 수 있다.
그리고 판단부(130)는 제1 사운드 출력정보의 레벨이 제2 레벨이면, 상기 제1 사운드 출력정보 및 상기 제2 사운드 출력정보를 제1 시간 동안 출력할 수 있다. 또한, 판단부(130)는 제2 사운드 출력정보를 제1 시간에 연속하는 제2 시간 동안 출력하도록 판단할 수 있다. 이 때, 제1 시간 동안 상기 제1 사운드 출력정보의 크기는 상기 제2 사운드 출력정보의 크기보다 클 수 있다. 이러한 구성에 의하여, 차량 주행 중의 안정성 향상이 이루어질 수 있다.
또한, 가상 엔진(가상화 환경) 또는 호스트 운영체제에 탑재된(또는 임베디드된) 운영체제(예로, 게스트 운영체제 등) 내의 사운드 클라이언트는 각 운영체제 등과 연결된 디스플레이 장치 등으로 사운드 출력정보를 수신 또는 요청할 수 있다. 사운드 출력정보의 수신 및 요청은 출력이 요구되는 사운드 데이터를 의미할 수 있다.
그리고 가상 엔진 또는 컨테이너 또는 베이스 운영 체제 내에 탑재된 사운드 서버는 데이터 즉 사운드 출력정보를 수신하여 출력 인터페이스인 스피커 등을 통해 사운드를 출력하도록 하드웨어로 사운드 출력 정보를 소신할 수 있다. 이 때, 사운드 출력정보 즉 데이터는 가상 엔진 또는 호스트 운영체제에 탑재된(또는 임베디드된) 운영체제(예로, 게스트 운영체제 등) 내의 사운드 클라이언트를 통해 디스플레이 장치로 전달되어 사용자에게 제공될 수 있다.
또한, 송신부(140)는 최종 판단된 제1 사운드 출력정보 및 제2 사운드 출력정보 중 적어도 하나를 하드웨어 등으로 송신할 수 있다. 이를 통해, 차량의 전면 또는 후면 사운드 출력장치(예로, 스피커)를 통해 사운드가 출력될 수 있다.
도 15 내지 도 19를 참조하면, 실시예에 따른 차량 가상화 구조 기반의 사운드 제어 방법은 제1 사운드 클라이언트로부터 제1 사운드 출력정보 및 제2 사운드 클라이언트로부터 제2 사운드 출력정보 중 적어도 하나를 수신하는 단계(S510), 수신된 상기 제1 사운드 출력정보 및 상기 제2 사운드 출력정보에 대한 우선순위를 비교하는 단계(S520) 및 비교 결과에 대응하여 제1 사운드 출력정보 및 제2 사운드 출력정보 중 적어도 하나를 하드웨어로 송신하는 단계(S530)을 포함할 수 있다. 이하에서, 각 단계는 상술한 차량 가상화 구조 기반의 사운드 제어 장치에 의해 수행될 수 있다.
그리고 제1 사운드 클라이언트 및 상기 제2 사운드 클라이언트는 서로 다른 가상엔진 상에 탑재되며, 제1 사운드 클라이언트는 클러스터 운영체제에 탑재되고, 상기 제2 사운드 클라이언트는 AVN(Audio Video Navigation) 운영체제, 코-드라이버(Co-Driver) 운영체제, RSE(Rear Seat Entertainment) 운영체제에 탑재될 수 있다.
또한, 제1 사운드 출력정보의 우선순위는 상기 제2 사운드 출력정보의 우선순위보다 높을 수 있다.
그리고 우선순위를 비교한(S520) 이후에, 제1 사운드 출력정보의 발생 시점이 차량의 주행중인지 여부를 확인할 수 있다(S540).
실시예로, 제1 사운드 출력정보의 발생 시점이 차량의 주행중이 아니라면, 제1 사운드 출력정보를 출력한 후 제2 사운드 출력정보를 출력할 수 있다(S550). 예컨대, 주행이 시작되기 전에 인포테인먼트부의 오디오 재생 전 구동부의 알림음의 재생이 필요할 수 있다. 이 경우, 도 17과 같이 구동부의 알림(제1 사운드 출력정보)을 특정 시간(ta)까지 먼저 출력하고, 인포테인먼트부의 오디오(제2 사운드 출력 정보)가 특정 시간(ta)이후에 출력될 수 있다. 즉, 시동을 켠 후, AVN의 라디오 등 미디어 재생 전에 연료 부족 알림, 소모품 교체 알림 등의 알림음이 우선적으로 출력(재생)될 수 있다. 다시 말해, 비교 결과에 대응하여 제1 사운드 출력정보 및 제2 사운드 출력정보(차량 주행중에는 제1 사운드 출력정보 송신 후 제2 사운드 출력 정보 송신) 중 적어도 하나를 송신할 수 있다.
그리고 제1 사운드 출력정보의 발생 시점이 차량의 주행중이라면 상기 제1 사운드 출력정보의 레벨에 따라 상기 제1 사운드 출력정보 및 제2 사운드 출력정보의 출력 여부 및 출력 시간을 조절하여 출력할 수 있다(S570). 여기서, 출력정보의 레벨은 제1 레벨 및 상기 제1 레벨보다 낮은 제2 레벨을 포함할 수 있다.
그리고 제1 사운드 출력정보의 레벨이 제1 레벨인지 판단할 수 있다. 제1 사운드 출력정보의 레벨이 제1 레벨이면 제1 사운드 출력정보만 출력하고, 제2 사운드 출력정보의 출력을 차단할 수 있다(S580).
예컨대, 차량의 주행중에 구동부의 오디오(또는 사운드)를 출력하고 인포테인먼트부의 오디오를 음소거(mute)할 수 있다. 이를 통해, 운전자가 위험 상태를 완전하게 인지하게 되어 사고 발생이 억제될 수 있다. 즉, 도 18과 같이, 제1 사운드 출력정보만이 출력되고 제2 사운드 출력정보의 출력이 차단될 수 있다.
예컨대, 주행 중 차량 구동부 고장, 졸음 방지 경고음 등(제1 사운드 출력 정보)이 인포테인먼트부의 오디오(제2 사운드 출력정보)가 차단된 상태에서 출력되어야 하므로, 제1 사운드 출력정보만이 하드웨어로 송신될 수 있다.
그리고 제1 사운드 출력정보의 레벨이 제2 레벨이면, 제1 사운드 출력정보 및 상기 제2 사운드 출력정보를 제1 시간 동안 출력하고(S590), 제2 사운드 출력정보를 제1 시간에 연속하는 제2 시간 동안 출력할 수 있다(S595).
도 19를 참조하면, 제1 시간(t1)까지 제1 사운드 출력정보 및 제2 사운드 출력 정보를 출력할 수 있다. 이 때, 제1 시간(t1) 동안 상기 제1 사운드 출력정보의 크기(AM1)는 상기 제2 사운드 출력정보의 크기(AM2)보다 클 수 있다. 이에, 운전자는 제1 사운드 출력정보의 오디오를 용이하게 인지할 수 있다.
이로써, 주행 중 차선 이탈 경보음, 소모품 교체 알림 등의 순간적 주의를 요구하는 제1 사운드 출력정보가 운전자에게 용이하게 제공될 수 있다.
나아가, 제2 사운드 출력정보만을 수신하면 상기 송신하는 단계에서 상기 제2 사운드 출력정보를 상기 하드웨어로 송신할 수 있다.
이 대, 디스플레이 장치들이 오디오 데이터를 출력하는 경우, 이들 장치 간의 우선순위가 존재할 수 있다. 예컨대, AVN, RSE, Co-drive, 순으로 운선순위가 설정될 수 있다.
예를 들어, AVN만 오디오 출력이 이루어지는 경우, 차량의 모든 사운드 장치(이하, 스피커)가 해당 오디오를 출력할 수 있다. 그리고 AVN과 RSE가 동시에 오디오 출력을 수행하는 경우, 차량의 전면부 상에 오디오가 출력되는 경우, 차량의 전면부 스피커는 AVN의 오디오 출력이 출력되고, 차량의 후면부 스피커는 RSE의 오디오 출력이 출력될 수 있다. 또한, AVN과 Co-drive가 동시에 오디오 출력을 수행하는 경우, AVN과 Co-drive 중 최근에 출력된 오디오 출력이 차량의 모든 스피커로 출력될 수 있다.
도 20은 변형예에 따른 차량 가상화 구조 기반의 시스템의 개념도이다.
상술한 바와 같이 실시예에 따른 차량 가상화 구조 기반의 시스템은 하드웨어(미도시됨), 하드웨어(미도시됨) 상에 탑재된 베이스 운영 체제(10), 베이스 운영 체제(10) 상에 탑재된 적어도 하나의 운영체제(30a 내지 30f), 적어도 하나의 운영체제(30a 내지 30f) 상에 탑재되고 미들웨어 및 중요 애플리케이션이 포함된 소프트웨어 집합으로 복수의 운영체제 플랫폼(40a 내지 40f), 운영체제 플랫폼(40a 내지 40f)에서 구동되는 복수의 애플리케이션(50a 내지 50d), 복수의 운영체제 플랫폼(40a 내지 40f) 또는 복수의 애플리케이션 등을 출력하는 복수의 디스플레이(60a 내지 60f) 및 가상엔진(20a 내지 20b) 상에서 복수의 운영체제(30a 내지 30d)에 대한 환경을 관리하는 컨테이너 관리부(CM)를 포함할 수 있다. 적어도 하나의 운영체제는 이하 '컨테이너(container)'로 설명한다. 즉, 상술한 가상엔진 없이 도 20에 도시된 차량 가상화 구조 기반의 시스템으로 상술한 사운드 제어가 수행될 수 있다.
상술한, 본 발명의 실시예는 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터에 의해 실행 가능한 명령어를 포함하는 기록 매체의 형태로도 구현될 수 있다. 컴퓨터 판독 가능 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 가용 매체 일 수 있고, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체를 모두 포함한다. 또한, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분 리형 및 비분리형 매체를 모두 포함할 수 있다.
또한, 본 실시예에서 설명한 차량용 소프트웨어 제어 장치는 컴퓨터 구현 가능한 저장매체에 저장된 컴퓨터 프로그램으로 구현될 수 있다. 또한, 본 실시예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(field-programmable gate array) 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행할 수 있다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함할 수 있다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
이상에서 실시예를 중심으로 설명하였으나 이는 단지 예시일 뿐 본 발명을 한정하는 것이 아니며, 본 발명이 속하는 분야의 통상의 지식을 가진 자라면 본 실시예의 본질적인 특성을 벗어나지 않는 범위에서 이상에 예시되지 않은 여러 가지의 변형과 응용이 가능함을 알 수 있을 것이다. 예를 들어, 실시예에 구체적으로 나타난 각 구성 요소는 변형하여 실시할 수 있는 것이다. 그리고 이러한 변형과 응용에 관계된 차이점들은 첨부된 청구 범위에서 규정하는 본 발명의 범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (10)

  1. 복수의 컨테이너를 부팅하는 단계;
    상기 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계; 및
    상기 업그레이드의 필요성에 대응하여 상기 복수의 컨테이너에 대한 업그레이드를 수행하는 단계;를 포함하고,
    상기 복수의 컨테이너는 시스템 초기화 및 관리를 공유하는 차량 가상화 구조 기반의 제어 방법.
  2. 제1항에 있어서,
    상기 복수의 컨테이너의 업그레이드의 필요성을 확인하는 단계는,
    업그레이드 정보를 수신하는 단계;
    상기 업그레이드 정보와 상기 복수의 컨테이너의 업그레이드를 비교하는 단계; 및
    상기 업그레이드의 필요성을 결정하는 단계;를 포함하는 차량 가상화 구조 기반의 제어 방법.
  3. 제2항에 있어서,
    상기 업그레이드의 필요성이 없는 경우에 상기 복수의 컨테이너를 구동하는 단계;를 더 포함하는 차량 가상화 구조 기반의 제어 방법.
  4. 제2항에 있어서,
    상기 업그레이드의 필요성이 존재하는 경우에 시스템 디렉터리에 대한 업그레이드 또는 사용자 데이터(personal data)에 대한 업그레이드인지 판단하는 단계;를 더 포함하는 차량 가상화 구조 기반의 제어 방법.
  5. 제4항에 있어서,
    상기 시스템 디렉터리에 대한 업그레이드인 경우, 업그레이드인지 판단하는 단계 이후에,
    사용자 인증을 수행하는 단계; 및
    상기 시스템 디렉터리를 수신하는 단계;를 더 포함하는 차량 가상화 구조 기반의 제어 방법.
  6. 제5항에 있어서,
    상기 복수의 컨테이너를 재부팅하는 단계;를 더 포함하고,
    상기 업그레이드의 필요성을 확인하는 단계로 돌아가는 차량 가상화 구조 기반의 제어 방법.
  7. 제4항에 있어서,
    상기 사용자 데이터에 대한 업그레이드인 경우 업그레이드인지 판단하는 단계 이후에,
    최신의 사용자 데이터를 수신하는 단계; 및
    상기 복수의 컨테이너를 구동하는 단계;를 더 포함하는 차량 가상화 구조 기반의 제어 방법.
  8. 제3항 또는 제7항에 있어서,
    상기 복수의 컨테이너를 구동하는 단계 이후에,
    상기 컨테이너와 연결된 디스플레이로 어플리케이션을 실행하는 단계;를 더 포함하는 차량 가상화 구조 기반의 제어 방법.
  9. 제7항에 있어서,
    상기 복수의 컨테이너를 구동하는 단계에서,
    상기 사용자 데이터 중 변경 디렉토리 카피하여 상기 복수의 컨테이너를 구동하는 차량 가상화 구조 기반의 제어 방법.
  10. 제7항에 있어서,
    상기 공유된 시스템 초기화 및 관리는 커널(kernel), 디스트로(distro) 및 라이브러리(library)를 포함하는 차량 가상화 구조 기반의 제어 방법.
PCT/KR2020/017113 2020-11-27 2020-11-27 차량 가상화 구조 기반의 시스템 제어 방법 및 장치 WO2022114291A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023544019A JP2023543957A (ja) 2020-11-27 2020-11-27 車両の仮想化構造に基づくシステムの制御方法および装置｛ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｃｏｎｔｒｏｌｌｉｎｇ ｖｉｒｔｕａｌｉｚｅｄ ｖｅｈｉｃｌｅ ｓｔｒｕｃｔｕｒｅ－ｂａｓｅｄ ｓｙｓｔｅｍ｝
PCT/KR2020/017113 WO2022114291A1 (ko) 2020-11-27 2020-11-27 차량 가상화 구조 기반의 시스템 제어 방법 및 장치
US18/029,127 US20230367579A1 (en) 2020-11-27 2020-11-27 Method and apparatus for controlling virtualized vehicle structure-based system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2020/017113 WO2022114291A1 (ko) 2020-11-27 2020-11-27 차량 가상화 구조 기반의 시스템 제어 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2022114291A1 true WO2022114291A1 (ko) 2022-06-02

Family

ID=81755732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/017113 WO2022114291A1 (ko) 2020-11-27 2020-11-27 차량 가상화 구조 기반의 시스템 제어 방법 및 장치

Country Status (3)

Country Link
US (1) US20230367579A1 (ko)
JP (1) JP2023543957A (ko)
WO (1) WO2022114291A1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120143402A1 (en) * 2010-12-06 2012-06-07 Kia Motors Corporation System and method for updating vehicle information using wireless access point connected to telematics server
KR20200019565A (ko) * 2018-08-14 2020-02-24 현대자동차주식회사 차량용 무선 소프트웨어 업데이트 방법 및 장치

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110239209A1 (en) * 2010-03-23 2011-09-29 Fujitsu Limted System and methods for remote maintenance in an electronic network with multiple clients
US20160139737A1 (en) * 2014-11-13 2016-05-19 Microsoft Technology Licensing, Llc Application containers and application container generator
US9996374B2 (en) * 2015-06-16 2018-06-12 Assured Information Security, Inc. Deployment and installation of updates in a virtual environment
EP3416052B1 (en) * 2016-02-11 2020-11-25 Hyundai Motor Company Method and device for wirelessly updating software for vehicle
US10203947B2 (en) * 2016-08-03 2019-02-12 Toyota Infotechnology Center Usa, Inc. Efficient over-the-air software update for a connected vehicle
US10360020B2 (en) * 2017-04-11 2019-07-23 Nio Usa, Inc. Virtual machine (VM) approach to embedded system hot update
US10740132B2 (en) * 2018-01-30 2020-08-11 Veritas Technologies Llc Systems and methods for updating containers
US10939262B2 (en) * 2018-03-01 2021-03-02 The Trustees Of Princeton University System and method for bringing programmability and connectivity into isolated vehicles
EP3623939A1 (en) * 2018-08-14 2020-03-18 Hyundai Motor Company Method and apparatus for wirelessly updating software for vehicle
KR20220098788A (ko) * 2019-11-15 2022-07-12 엘지전자 주식회사 컨테이너 기반의 차량 시스템에서 심리스 컨테이너 업데이트
US10802481B1 (en) * 2019-12-20 2020-10-13 Kitty Hawk Corporation Site local servers for vehicle management

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120143402A1 (en) * 2010-12-06 2012-06-07 Kia Motors Corporation System and method for updating vehicle information using wireless access point connected to telematics server
KR20200019565A (ko) * 2018-08-14 2020-02-24 현대자동차주식회사 차량용 무선 소프트웨어 업데이트 방법 및 장치

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MASEK PHILIP, THULIN MAGNUS: "Container Based Virtualisation for Software Deployment in Self-Driving Vehicles Master's thesis in Software Engineering", CHALMERS UNIVERSITY OF TECHNOLOGY. GOTHENBURG, SWEDEN 2016, 1 January 2016 (2016-01-01), pages 1 - 75, XP055935331 *
MORABITO ROBERTO; PETROLO RICCARDO; LOSCRI VALERIA; MITTON NATHALIE; RUGGERI GIUSEPPE; MOLINARO ANTONELLA: "Lightweight virtualization as enabling technology for future smart cars", 2017 IFIP/IEEE SYMPOSIUM ON INTEGRATED NETWORK AND SERVICE MANAGEMENT (IM), 8 May 2017 (2017-05-08), pages 1238 - 1245, XP033127749, DOI: 10.23919/INM.2017.7987466 *
WANG YUJING, BAO QINYANG: "Adapting a Container Infrastructure for Autonomous Vehicle Development", ARXIV.ORG, 19 November 2019 (2019-11-19), 201 Olin Library Cornell University Ithaca, NY 14853 , pages 1 - 6, XP055847178 *

Also Published As

Publication number Publication date
US20230367579A1 (en) 2023-11-16
JP2023543957A (ja) 2023-10-18

Similar Documents

Publication Publication Date Title
WO2020149520A1 (ko) 펌웨어 업데이트 방법, 이를 위한 전자 장치 및 저장 매체
US8996864B2 (en) System for enabling multiple execution environments to share a device
US6928543B2 (en) System for real-time adaptation to changes in display configuration
WO2020218742A1 (ko) 폴더블 전자 장치 및 그 동작 방법
US8843926B2 (en) Guest operating system using virtualized network communication
WO2020171427A1 (ko) 어플리케이션을 프리페치하는 전자 장치 및 방법
WO2018139857A1 (en) Electronic device and method for managing data in electronic device
US20180060588A1 (en) Operating system
WO2020080767A1 (en) Method for controlling execution of heterogeneous operating systems and electronic device and storage medium therefor
WO2022163983A1 (ko) 차량 가상화 구조 기반의 디바이스 제어 방법 및 장치
WO2021118125A1 (ko) 안드로이드 어플리케이션에 의해 실행 가능한 보안 컨테이너 구축 장치, 방법 및 그 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체
WO2020059957A1 (ko) 차량용 소프트웨어 제어 장치
WO2020106019A1 (en) Electronic device and method for providing in-vehicle infotainment service
WO2018208032A1 (ko) 고립된 사용자컴퓨팅부를 갖는 컴퓨터
WO2021187818A1 (ko) 전자 장치 및 전자 장치의 테마를 부분적으로 운용하는 방법
WO2020218743A1 (en) Method for controlling execution of application, electronic device and storage medium for the same
EP3803585A1 (en) Electronic device for executing multiple operating systems and method of controlling same
WO2019059671A1 (en) ELECTRONIC DEVICE AND ITS CONTROL METHOD
WO2022114291A1 (ko) 차량 가상화 구조 기반의 시스템 제어 방법 및 장치
KR102449979B1 (ko) 차량 가상화 구조 기반의 시스템 제어 방법 및 장치
WO2024025199A1 (ko) 컴퓨팅 장치 및 그 동작 방법
WO2021045406A1 (en) Electronic device configured to perform action using speech recognition function and method for providing notification related to action using same
WO2018105965A1 (en) Vehicle operating method and vehicle operating apparatus
KR102491361B1 (ko) 차량 가상화 구조 기반의 시스템 제어 방법 및 장치
EP2306312A1 (en) Virtual computer device, virtual computer system, virtual computer program, and control method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20963686

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023544019

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20963686

Country of ref document: EP

Kind code of ref document: A1