WO2023136373A1 - 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치 - Google Patents

신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치 Download PDF

Info

Publication number
WO2023136373A1
WO2023136373A1 PCT/KR2022/000619 KR2022000619W WO2023136373A1 WO 2023136373 A1 WO2023136373 A1 WO 2023136373A1 KR 2022000619 W KR2022000619 W KR 2022000619W WO 2023136373 A1 WO2023136373 A1 WO 2023136373A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
data
virtual machine
machine
remote procedure
Prior art date
Application number
PCT/KR2022/000619
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 PCT/KR2022/000619 priority Critical patent/WO2023136373A1/ko
Publication of WO2023136373A1 publication Critical patent/WO2023136373A1/ko

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

  • the present invention relates to a signal processing device and a vehicle display device including the same, and more particularly, to a signal processing device capable of efficiently using resources between a plurality of virtual machines, and a vehicle display device including the same.
  • a vehicle is a device that allows a user to move in a desired direction.
  • a typical example is a car.
  • a vehicle display device is mounted inside the vehicle.
  • a display is arranged in a cluster or the like to display various types of information.
  • various displays such as AVN (Audio Video Navigation) displays, are being installed in vehicles separately from clusters.
  • AVN Audio Video Navigation
  • a vehicle display device is being researched to provide an integrated user experience using a plurality of virtual machines.
  • a remote procedure call based on network communication is used for service use.
  • this remote procedure call method has problems in that processor usage is increased and response delay occurs due to network use for other purposes. Furthermore, there is a disadvantage in that the remote procedure call cannot be used before the network is activated at the beginning of system booting.
  • US Patent Publication No. US7941800 discloses data transmission between virtual machines through a virtual machine bus operating in a pipe mode.
  • An object of the present invention is to provide a signal processing device capable of efficiently using resources between a plurality of virtual machines, and a display device for a vehicle having the same.
  • Another object of the present invention is to provide a signal processing device capable of reducing a call and response delay time when a remote procedure is called between a plurality of virtual machines, and a display device for a vehicle having the same.
  • Another object of the present invention is to provide a signal processing device capable of integrating data sharing and remote procedure call, and a vehicle display device having the same.
  • another object of the present invention is to provide a signal processing device capable of realizing rapid interaction between virtual machines even when the number of virtual machines increases, and a display device for a vehicle having the same.
  • a signal processing device for achieving the above object, and a vehicle display device having the same include a processor that performs signal processing for a display mounted on a vehicle, and the processor includes a hyperlink in the processor.
  • a plurality of virtual machines are executed on the visor, and a first virtual machine and a second virtual machine among the plurality of virtual machines share a shared area for remote procedure call in a shared memory in the hypervisor, and the first virtual machine executes a first call interface for access to a mutually shared area with a callee receiving data corresponding to a caller of the second virtualization machine, and the second virtualization machine, with the caller for remote procedure call, mutually Execute a second call interface for access to the shared area.
  • the second virtual machine may record call-related information in the mutual sharing area and notify the first virtual machine, and the first virtual machine may receive data in the mutual sharing area.
  • the first virtualization machine records result data processed based on the received data in a mutual sharing area and notifies the second virtualization machine, and the second virtualization machine receives the result data recorded in the mutual sharing area. can do.
  • the first virtualization machine or the second virtualization machine may control data exceeding the capacity of the mutual sharing area to be stored in a separate area within the shared memory.
  • the second call interface controls copying of the parameter data and meta data to a mutually shared area in the case of parameter data transmitted by the caller, and transfers data corresponding to the pointer to the call storage area in the shared memory in the case of a pointer parameter. can be controlled to
  • the first call interface or the second call interface may create or manage a control page in the shared memory or create or manage a mutually shared area.
  • the first call interface or the second call interface may control to create or delete a remote procedure call channel including a mutual sharing area and a call storage area.
  • the first call interface or the second call interface interacts with a host driver outside the shared memory through a control page table and control page in the shared memory, and is a remote procedure call channel including a mutually shared area and a call storage area. can be controlled to create or delete.
  • the first call interface or the second call interface may control to create or delete a control page through a host driver.
  • the first call interface or the second call interface may control to generate the number of control pages corresponding to the number of remote procedure call related service providers.
  • the first call interface or the second call interface may control to create a number of remote procedure call channels corresponding to the number of remote procedure call related service providers.
  • the first call interface or the second call interface may control data having a size exceeding the mutual sharing area to be stored in the call storage area, and control to record the address of the call storage area in the mutual sharing area.
  • the first call interface or the second call interface may control data having a size exceeding the mutual sharing area to be stored in the call storage area, and control to record the address of the call storage area in the mutual sharing area.
  • the first call interface may control to store screen capture data in the call storage area and record the address of the call storage area in the mutual sharing area.
  • the first virtualization machine may receive data on the control page table in the shared memory and register the first remote procedure call service based on the received data on the control page table.
  • the second virtualization machine may make a request to the shared memory to create a remote procedure call channel including a mutually shared area and a call storage area in the shared memory and receive information on the created remote procedure call channel.
  • the first virtual machine may control data to be transmitted to the second virtual machine by using the mutual sharing area.
  • the first virtual machine may repeatedly receive sensing data and control the sensing data to be transmitted to the second virtual machine using a mutual sharing area.
  • the second virtualization machine operates for the first display
  • the processor further executes the third virtualization machine for the second display
  • the second virtualization machine uses the second mutual sharing area in the shared memory, It may control to request music play information to the third virtual machine, receive music play information recorded in the second mutual sharing area, and display the music play information on the first display.
  • the second virtualization machine operates for the first display
  • the processor further executes the third virtualization machine for the second display
  • the second virtualization machine uses the second mutual sharing area in the shared memory, It may request screen theme information to the third virtualization machine, receive screen theme information recorded in the second mutual sharing area, and display the screen theme information on the first display.
  • a signal processing device includes a processor that performs signal processing for a display mounted on a vehicle, and the processor, on a hypervisor in the processor, a plurality of virtualization
  • a first virtual machine and a second virtual machine among a plurality of virtual machines share a mutually shared area for remote procedure call in a shared memory in a hypervisor, and the first virtual machine comprises the second virtual machine.
  • the second virtual machine may record call-related information in the mutual sharing area and notify the first virtual machine, and the first virtual machine may receive data in the mutual sharing area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first virtualization machine records result data processed based on the received data in a mutual sharing area and notifies the second virtualization machine, and the second virtualization machine receives the result data recorded in the mutual sharing area. can do. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first virtualization machine or the second virtualization machine may control data exceeding the capacity of the mutual sharing area to be stored in a separate area within the shared memory. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the second call interface controls copying of the parameter data and meta data to a mutually shared area in the case of parameter data transmitted by the caller, and transfers data corresponding to the pointer to the call storage area in the shared memory in the case of a pointer parameter.
  • the first call interface or the second call interface may create or manage a control page in the shared memory or create or manage a mutually shared area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface may control to create or delete a remote procedure call channel including a mutual sharing area and a call storage area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface interacts with a host driver outside the shared memory through a control page table and control page in the shared memory, and is a remote procedure call channel including a mutually shared area and a call storage area. can be controlled to create or delete. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface may control to create or delete a control page through a host driver. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface may control to generate the number of control pages corresponding to the number of remote procedure call related service providers. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface may control to create a number of remote procedure call channels corresponding to the number of remote procedure call related service providers. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface may control data having a size exceeding the mutual sharing area to be stored in the call storage area, and control to record the address of the call storage area in the mutual sharing area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface or the second call interface may control data having a size exceeding the mutual sharing area to be stored in the call storage area, and control to record the address of the call storage area in the mutual sharing area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first call interface may control to store screen capture data in the call storage area and record the address of the call storage area in the mutual sharing area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first virtualization machine may receive data on the control page table in the shared memory and register the first remote procedure call service based on the received data on the control page table. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the second virtualization machine may make a request to the shared memory to create a remote procedure call channel including a mutually shared area and a call storage area in the shared memory and receive information on the created remote procedure call channel. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first virtual machine may control data to be transmitted to the second virtual machine by using the mutual sharing area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines.
  • the first virtual machine may repeatedly receive sensing data and control the sensing data to be transmitted to the second virtual machine using a mutual sharing area. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to efficiently use resources when sensing data is transmitted between a plurality of virtual machines.
  • the second virtualization machine operates for the first display
  • the processor further executes the third virtualization machine for the second display
  • the second virtualization machine uses the second mutual sharing area in the shared memory, It may control to request music play information to the third virtual machine, receive music play information recorded in the second mutual sharing area, and display the music play information on the first display. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to efficiently use resources when transmitting music reproduction information between a plurality of virtual machines. Furthermore, even if the number of virtual machines increases, it is possible to implement rapid interaction between virtual machines.
  • the second virtualization machine operates for the first display
  • the processor further executes the third virtualization machine for the second display
  • the second virtualization machine uses the second mutual sharing area in the shared memory, It may request screen theme information to the third virtualization machine, receive screen theme information recorded in the second mutual sharing area, and display the screen theme information on the first display. Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to efficiently use resources when transmitting screen theme information between a plurality of virtual machines.
  • 1A is a diagram illustrating an example of a vehicle exterior and a vehicle interior.
  • 1B is a view showing another example of the inside of a vehicle.
  • FIG. 2 is a diagram illustrating an appearance of a display device for a vehicle according to an embodiment of the present invention.
  • FIG. 3 illustrates an example of an internal block diagram of the vehicle display device of FIG. 2 .
  • FIG. 4 is a diagram showing a system driven by a signal processing device related to the present invention.
  • FIG. 5 is a diagram showing an example of a system driven by a signal processing apparatus according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating another example of a system driven by a signal processing apparatus according to an embodiment of the present invention.
  • FIG. 7 is a diagram showing another example of a system driven by a signal processing apparatus according to an embodiment of the present invention.
  • FIG. 8 to 9B are views referred to in the description of FIG. 5 .
  • FIGS. 10A and 10B are diagrams for explaining a signal processing device related to the present invention.
  • FIG. 11 is a diagram illustrating an internal operation of a signal processing apparatus according to an embodiment of the present invention.
  • FIG. 12 to 16d are views referred to in the description of FIG. 11 .
  • module and “unit” for the components used in the following description are simply given in consideration of ease of writing this specification, and do not themselves give a particularly important meaning or role. Accordingly, the “module” and “unit” may be used interchangeably.
  • 1A is a diagram illustrating an example of a vehicle exterior and a vehicle interior.
  • the vehicle 200 is operated by a plurality of wheels 103FR, 103FL, 103RL, .. rotated by a power source, and a steering wheel 150 for adjusting the traveling direction of the vehicle 200. .
  • the vehicle 200 may further include a camera 195 for obtaining an image of the front of the vehicle.
  • the vehicle 200 may include a plurality of displays 180a and 180b for displaying images and information therein.
  • FIG. 1A illustrates a cluster display 180a and an audio video navigation (AVN) display 180b as the plurality of displays 180a and 180b.
  • APN audio video navigation
  • HUD Head Up Display
  • the AVN (Audio Video Navigation) display 180b may also be named a center information display (Center Information Dislpay).
  • the vehicle 200 described in this specification may be a concept that includes all of a vehicle including an engine as a power source, a hybrid vehicle including an engine and an electric motor as a power source, and an electric vehicle including an electric motor as a power source. there is.
  • 1B is a view showing another example of the inside of a vehicle.
  • a cluster display 180a inside the vehicle, a cluster display 180a, an AVN (Audio Video Navigation) display 180b, rear seat entertainment displays 180c and 180d, and a room mirror display (not shown) etc. can be installed.
  • AVN Audio Video Navigation
  • FIG. 2 is a diagram illustrating an appearance of a display device for a vehicle according to an embodiment of the present invention.
  • a vehicle display device 100 is a signal processing device that performs signal processing for displaying images and information on a plurality of displays 180a to 180b and a plurality of displays 180a to 180b. (170) may be provided.
  • the first display 180a is a cluster display 180a for displaying driving conditions and operation information
  • the second display 180b displays vehicle driving information, navigation maps, and various other information. It may be an AVN (Audio Video Navigation) display 180b for displaying entertainment information or images.
  • AVN Audio Video Navigation
  • the signal processing device 170 includes a processor 175 therein, and may execute first to third virtual machines 520 to 540 on the hypervisor 505 in the processor 175 .
  • the second virtualization machine 530 may operate for the first display 180a, and the third virtualization machine 540 may operate for the second display 180b.
  • the first virtualization machine 520 in the processor 175 receives sensor data from the sensor device 760 in the vehicle 100 and a radio signal from the tuner 105 in the vehicle 100, and receives the received data.
  • Sensor data or data corresponding to a radio signal is transmitted to at least one of the second virtualization machine 530 and the third virtualization machine 540 . Accordingly, it is possible to efficiently use resources among a plurality of virtual machines. In particular, it is possible to reduce call and response delay time between a plurality of virtual machines. Furthermore, even if the operating systems of a plurality of virtual machines are different, sensor data can be quickly shared.
  • the hypervisor 505-based shared memory 508 can be controlled to be set. Accordingly, the same information or the same image can be synchronized and displayed on the first display 180a and the second display 180b in the vehicle.
  • the first virtualization machine 520 in the processor 175 shares at least a portion of data with the second virtualization machine 530 and the third virtualization machine 540 for data sharing processing. Accordingly, it is possible to divide and process data in a plurality of virtual machines for a plurality of displays in the vehicle.
  • the first virtualization machine 520 in the processor 175 receives and processes wheel speed sensor data of the vehicle, and processes the processed data into at least one of the second virtualization machine 530 and the third virtualization machine 540.
  • Wheel speed sensor data can be transmitted. Accordingly, wheel speed sensor data of the vehicle can be shared with at least one virtual machine or the like.
  • the vehicle display device 100 further includes a rear seat entertainment display 180c for displaying driving state information, simple navigation information, various entertainment information or images.
  • a rear seat entertainment display 180c for displaying driving state information, simple navigation information, various entertainment information or images.
  • the signal processing device 170 executes a fourth virtual machine (not shown) in addition to the first virtual machine to the third virtual machine 520 to 540 on the hypervisor 505 in the processor 175 to perform RSE.
  • the display 180c may be controlled.
  • some of the plurality of displays 180a to 180c may operate based on a Linux OS, and some may operate based on a web OS.
  • the signal processing device 170 is configured to receive a touch input from any one of a plurality of displays 180a to 180b or 180a to 180c operating under various operating systems (OS). In this case, it is possible to control the touch input to be processed quickly and accurately.
  • OS operating systems
  • the vehicle speed indicator 212a and the vehicle internal temperature indicator 213a are displayed on the first display 180a, and a plurality of applications and the vehicle speed indicator 212b are displayed on the second display 180b. and the vehicle interior temperature indicator 213b are displayed, and a second home screen 222b including a plurality of applications and the vehicle interior temperature indicator 213c is displayed on the third display 180c. Illustrate what is displayed.
  • FIG. 3 illustrates an example of an internal block diagram of a display device for a vehicle according to an embodiment of the present invention.
  • a vehicle display device 100 includes an input unit 110, a communication unit 120, an interface 130, a signal processing device 170, and a plurality of displays 180a to 180c. , an audio output unit 185, and a power supply unit 190.
  • the input unit 110 may include a physical button or pad for button input or touch input.
  • the input unit 110 may include a touch sensor (not shown) for sensing a touch input of the displays 180a, 180b, and 180c.
  • the input unit 110 may include a microphone (not shown) for user voice input.
  • the communication unit 120 may exchange data with the mobile terminal 800 or the server 900 in a wireless manner.
  • the communication unit 120 may wirelessly exchange data with a vehicle driver's mobile terminal.
  • a wireless data communication method various data communication methods such as Bluetooth, WiFi, WiFi Direct, and APiX are possible.
  • the communication unit 120 may receive weather information and road traffic condition information, eg, Transport Protocol Expert Group (TPEG) information, from the mobile terminal 800 or the server 900 . To this end, the communication unit 120 may include a mobile communication module (not shown).
  • TPEG Transport Protocol Expert Group
  • the interface 130 may receive sensor information or the like from the ECU 770 or the sensor device 760 and transmit the received information to the signal processing device 170 .
  • the sensor information includes vehicle direction information, vehicle location information (GPS information), vehicle angle information, vehicle speed information, vehicle acceleration information, vehicle tilt information, vehicle forward/reverse information, battery information, fuel information, tire information, vehicle It may include at least one of lamp information, vehicle internal temperature information, and vehicle internal humidity information.
  • Such sensor information includes heading sensor, yaw sensor, gyro sensor, position module, vehicle forward/backward sensor, wheel sensor, vehicle speed sensor, It may be obtained from a vehicle body tilt detection sensor, a battery sensor, a fuel sensor, a tire sensor, a steering sensor by steering wheel rotation, a vehicle internal temperature sensor, a vehicle internal humidity sensor, and the like.
  • the position module may include a GPS module for receiving GPS information.
  • the interface 130 receives image data from the front of the vehicle, image data from the sides of the vehicle, image data from the rear of the vehicle, distance information of obstacles around the vehicle, etc. from the camera 195 or a lidar (not shown), and signals the received information. processing device 170.
  • the audio output unit 185 converts the electrical signal from the signal processing device 170 into an audio signal and outputs it. To this end, a speaker or the like may be provided.
  • the power supply 190 may supply power required for operation of each component under the control of the signal processing device 170 .
  • the power supply unit 190 may receive power from a battery inside the vehicle.
  • the signal processing device 170 controls the overall operation of each unit in the vehicle display device 100 .
  • the signal processing device 170 may be implemented in the form of a System On Chip (SOC).
  • SOC System On Chip
  • the signal processing device 170 includes a processor 175 that performs signal processing for the vehicle displays 180a, 180b, and 180c, a first memory 140a and a second memory 140b for storing various data, and a microcomputer ( 135) may be provided.
  • the first memory 140a is a non-volatile memory and can store various types of data even in a standby mode or when power is turned off.
  • the first memory 140a may store a file corresponding to a first application executed in one of the plurality of virtual machines 510 to 550 based on entering the standby mode. .
  • the first memory 140a may store an operating system (OS).
  • OS operating system
  • the first memory 140a may store various data for overall operation of the vehicle display device 100, such as a program for processing or controlling the signal processing device 170.
  • the second memory 140b is a volatile memory, and various types of data are erased in a standby mode or when the power is turned off, and may temporarily store data in an active mode.
  • the second memory 140b may load a file stored in the first memory 140a based on a transition from the standby mode to the active mode.
  • the second memory 140b may load an operating system (OS) stored in the first memory 140a based on a transition from the standby mode to the active mode.
  • OS operating system
  • the processor 175 may drive a hypervisor (505 in FIG. 5).
  • the processor 175 may execute the first to fourth virtual machines 520 to 550 on a hypervisor (505 in FIG. 5) within the processor 175.
  • the processor 175 may further execute a legacy virtualization machine 510 that receives and processes Ethernet data.
  • the legacy virtualization machine as shown in FIG. 5 , may be executed in the first virtualization machine 520 within the processor 175 .
  • the first virtual machine 520 may be referred to as a server virtual machine
  • the second virtual machine to the fourth virtual machine (530 ⁇ 550) can be named a guest virtual machine (Guest Virtual Machine).
  • the second virtualization machine 530 operates for the first display 180a
  • the third virtualization machine 540 operates for the second display 180b
  • the fourth virtualization machine 550 It can operate for the third display 180c.
  • the first virtualization machine 520 in the processor 175 may receive vehicle sensor data, location information data, camera image data, audio data, or touch input data, and may process or process and output the received data.
  • vehicle sensor data location information data
  • camera image data location information data
  • audio data audio data
  • touch input data may process or process and output the received data.
  • data processing can be performed efficiently.
  • 1:N data sharing is possible.
  • the first virtual machine 520 directly receives and processes CAN communication data, audio data, radio data, USB data, and wireless communication data for the second to fourth virtual machines 530 to 550. can do.
  • the first virtualization machine 520 may transmit the processed data to the second to fourth virtualization machines 530 to 550 .
  • the first virtual machine 520 among the first to fourth virtual machines 520 to 550 receives communication data and external input data and performs signal processing, thereby processing signals in other virtual machines.
  • the burden is reduced, 1:N data communication becomes possible, and synchronization at the time of data sharing becomes possible.
  • the first virtualization machine 520 writes part of the data in the first shared memory (not shown) to be transferred to the second virtualization machine 530, and transfers another part of the data to the third virtualization machine. 1 is recorded in a shared memory (not shown), and the second virtual machine 530 and the third virtual machine 540 process the received data, respectively, and the processed data is recorded in a second shared memory (not shown). control as much as possible
  • the data at this time may be any one of video data, audio data, navigation data, or voice recognition data.
  • the first virtualization machine 520 may process another portion of data and control the processed data to be recorded in a second shared memory (not shown). That is, in addition to the second virtual machine 530 and the third virtual machine, the first virtual machine 520 may process data.
  • the fourth virtualization machine 550 operating for the third display 180c is executed in the processor 175, the first virtualization machine 520 stores another part of data in the first shared memory (not shown). ), and the fourth virtualization machine 550 may process each received data and control the processed data to be recorded in a second shared memory (not shown).
  • the first virtualization machine 520 may generate command queues for distributed processing of data in the second to fourth virtualization machines 530 to 550 . Accordingly, it is possible to divide and process data in a plurality of virtual machines.
  • the first virtual machine 520 in the processor 175 may generate one identical command queue when the second to fourth virtual machines 530 to 550 share the same data. Accordingly, the same data can be synchronized and shared.
  • the first virtualization machine 520 may generate command queues corresponding to the number of virtualization machines for distributed processing of data.
  • the first virtualization machine 520 may control transmission of at least a portion of data to at least one of the second virtualization machine 520 and the fourth virtualization machine 530 to 550 for data distribution processing.
  • the first virtualization machine 520 allocates a first shared memory (not shown) for transferring at least a portion of data to at least one of the second to fourth virtualization machines 530 to 550, and , Image data processed by the second virtualization machine 530 or the third virtualization machine 540 may be recorded in a second shared memory (not shown).
  • the first virtual machine 520 may record data in the shared memory 508 and control the second to fourth virtual machines 530 to 550 to share the same data.
  • the first virtualization machine 520 records radio data or wireless communication data in the shared memory 508 and controls the second to fourth virtualization machines 530 to 550 to share the same data. can do. Accordingly, it is possible to share data in a 1:N manner.
  • the first virtual machine 520 in the processor 175 uses a shared memory 508 based on the hypervisor 505 to transmit the same data to the second to fourth virtual machines 530 to 550. can be controlled to be set.
  • the first virtualization machine 520 in the processor 175 uses the shared memory 508 based on the hypervisor 505 to transfer the same data to the second to fourth virtualization machines 530 to 550. can be synchronized and transmitted. Accordingly, the same image can be synchronized and displayed on the plurality of displays 180a to 180c in the vehicle.
  • the signal processing device 170 may process various signals such as audio signals, video signals, and data signals.
  • the first virtualization machine 520 in the processor 175 receives sensor data from the sensor device 760 in the vehicle 100 and a radio signal from the tuner 105 in the vehicle 100, and generates sensor data Alternatively, data corresponding to the radio signal may be transmitted to at least one of the second virtualization machine 530 and the third virtualization machine 540 . Accordingly, it is possible to quickly share sensor data or data corresponding to a radio signal.
  • FIG. 4 is a diagram showing a system driven by a signal processing device related to the present invention.
  • FIG. 4 is a diagram illustrating that virtual machines are used for the cluster display 180a and the AVN display 180b, respectively.
  • the cluster virtualization machine 430 and the AVN virtualization machine 440 are executed on the hypervisor 405 in the processor 175 .
  • system 400 driven by the signal processing apparatus of FIG. 4 illustrates that a legacy virtual machine 410 is also executed on the hypervisor 405 in the processor 175 .
  • the legacy virtualization machine 410 includes an interface 412 for data communication with the memory 140 and an interface 413 for Ethernet communication.
  • the cluster virtual machine 430 includes an interface 431 for CAN communication, an interface 432 for communication with the interface 412 of the legacy virtual machine 410, and a legacy virtual machine 410 An interface 433 for communication with the interface 413 of ) may be provided.
  • the AVN virtualization machine 440 includes an interface 441 for input/output of audio data, radio data, USB data, and wireless communication data, and an interface for communication with the interface 412 of the legacy virtualization machine 410. 442, and an interface 443 for communication with the interface 413 of the legacy virtualization machine 410.
  • the AVN virtualization machine 440 since CAN communication data is input and output only in the cluster virtualization machine 430, the AVN virtualization machine 440 has a disadvantage in that CAN communication data cannot be utilized.
  • the cluster virtualization machine 430 and the cluster virtualization machine 430 have to have separate interfaces 431, 432, 441, 442, respectively. there is.
  • the virtual machine is divided into a server virtual machine and a guest virtual machine, and various memory data, communication data, etc. are input and output from the server virtual machine rather than from the guest virtual machine. This will be described with reference to FIG. 5 below.
  • FIG. 5 is a diagram showing an example of a system driven by a signal processing apparatus according to an embodiment of the present invention.
  • the system 500 of FIG. 5 includes a first virtualization machine 520, which is a server virtualization machine, and a second virtualization machine 520, which is a guest virtualization machine, on a hypervisor 505 in a processor 175 in a signal processing device 170.
  • the second virtualization machine 530 and the guest virtualization machine exemplify that the third virtualization machine 540 is executed.
  • the second virtualization machine 530 may be a virtualization machine for the cluster display 180a
  • the third virtualization machine 540 may be a virtualization machine for the AVN display 180b.
  • the second virtualization machine 530 and the third virtualization machine 540 may operate for image rendering of the cluster display 180a and the AVN display 180b, respectively.
  • system 500 driven by the signal processing device 170 of FIG. 5 illustrates that a legacy virtual machine 510 is also executed on the hypervisor 505 in the processor 175 .
  • the legacy virtual machine 510 includes an interface 511 for data communication with the memory 140 and Ethernet communication.
  • the interface 511 is a physical device driver, but various modifications are possible.
  • the legacy virtual machine 510 may further include a virtio-backend interface 512 for data communication with the second to third virtual machines 530 and 540 .
  • the first virtual machine 520 may include an interface 521 for input/output of audio data, radio data, USB data, and wireless communication data, and an input/output server interface 522 for data communication with a guest virtual machine. .
  • the first virtualization machine 520 which is a server virtualization machine, transfers I/Os that are difficult to virtualize by standard virtualization technology (VirtIO) to a plurality of guest virtualization machines, for example, the second to third virtualization machines 530 and 540. etc. can be provided.
  • VirtualIO virtualization technology
  • the first virtualization machine 520 which is a server virtualization machine, controls radio data, audio data, etc. at the level of a supervisor, and a plurality of guest virtualization machines, for example, second to third virtualization machines ( 530,540) and the like.
  • the first virtualization machine 520 may perform a supervisory service for system and display management, and a system service for external device connection control and vehicle 100 information management. Accordingly, it is possible to efficiently perform internal system management and the like.
  • the first virtualization machine 520 which is a server virtualization machine, processes vehicle data, sensor data, information around the vehicle, and the like, and transfers the processed data or information to a plurality of guest virtualization machines, for example, second to second virtualization machines.
  • 3 virtual machines 530 and 540 may be provided.
  • the first virtual machine 520 may provide supervisory services such as vehicle data processing and audio routing management.
  • the second virtual machine 530 may include an input/output client interface 532 for data communication with the first virtual machine 520 and APIs 533 that control the input/output client interface 532. .
  • the second virtualization machine 530 may have a virtio-backend interface for data communication with the legacy virtualization machine 510 .
  • the second virtualization machine 530 transmits memory data by communication with the memory 140 from an interface 512 of the legacy virtualization machine 510 through a virtio-backend interface. Alternatively, Ethernet data by Ethernet communication may be received.
  • the third virtual machine 540 may include an input/output client interface 542 for data communication with the first virtual machine 520 and APIs 543 controlling the input/output client interface 542.
  • the third virtualization machine 540 may have a virtio-backend interface for data communication with the legacy virtualization machine 510 .
  • the third virtualization machine 540 transmits memory data by communication with the memory 140 from an interface 512 of the legacy virtualization machine 510 through a virtio-backend interface. Alternatively, Ethernet data by Ethernet communication may be received.
  • legacy (legacy) virtual machine 510 unlike FIG. 5, it is also possible to be provided in the first virtual machine 520.
  • CAN communication data is input and output only in the first virtualization machine 520, but through data processing in the first virtualization machine 520, a plurality of guest virtualization machines, for example, the second virtualization machine 520. to third virtual machines 530 and 540. Accordingly, 1:N data communication by processing of the first virtualization machine 520 is possible.
  • audio data, radio data, USB data, and wireless communication data are input and output only in the first virtual machine 520, but through data processing in the first virtual machine 520.
  • a plurality of guest virtual machines, for example, second to third virtual machines 530 and 540 may be provided. Accordingly, 1:N data communication by processing of the first virtualization machine 520 is possible.
  • a touch input to the first display 180a or the second display 180b is input only to the first virtual machine 520, and the second to third It is not input to the virtual machines 530 and 540.
  • Information about the touch input is transmitted to the second virtual machine 530 or the third virtual machine 540 .
  • the second to third virtual machines 530 and 540 may operate based on different OSs.
  • the second virtualization machine 540 may operate based on a Linux OS, and the third virtualization machine 540 may operate based on a web OS.
  • the first virtual machine 520 may set the shared memory 508 based on the hypervisor 505 to share data even though the second to third virtual machines 530 and 540 operate under different OS bases. Accordingly, even if the second to third virtual machines 530 and 540 operate under different operating systems (OS), the same data or the same image can be synchronized and shared. As a result, the same data or the same image can be synchronized and displayed on the plurality of displays 180a and 180b.
  • OS operating systems
  • the first virtualization machine 520 transfers information about a touch input to the second virtualization machine 530 or the third virtualization machine 530 even though the second to third virtualization machines 530 and 540 operate under different OS bases. Send to machine 540. Accordingly, even if the second to third virtual machines 530 and 540 operate under different operating systems (OS), they can quickly and accurately process touch inputs.
  • OS operating systems
  • the first virtualization machine 520 through the second to third virtualization machines 530 and 540, displays a display manager 527 for controlling overlays displayed on the first display 180a and the second display 180b. and a display layer server 529.
  • the display layer server 529 may receive a first overlay provided by the second virtualization machine 530 and a second overlay provided by the third virtualization machine 540 .
  • the display layer server 529 may transmit a virtual overlay separate from the first overlay or the second overlay to at least one of the second virtual machine 530 and the third virtual machine 540. .
  • the display manager 527 in the first virtualization machine 520 transmits the first overlay provided by the second virtualization machine 530 and the second overlay provided by the third virtualization machine 540 to the display layer server. It can be received through (529).
  • the display manager 527 in the first virtualization machine 520 displays a virtual overlay separate from the first overlay or the second overlay through the display layer server 529, the second virtualization machine 530 ) or at least one of the third virtual machine 540.
  • the second virtualization machine 530 may synthesize the first overlay and the virtual overlay and control them to be displayed on the first display 180a.
  • the third virtualization machine 540 may synthesize the second overlay and the virtual overlay and control them to be displayed on the second display 180b.
  • the first virtual machine 520 may include an input manager 524 that receives an input signal from the outside.
  • the input signal at this time may be an input signal of a predetermined button (start button, etc.) in the vehicle, a touch input signal, or a voice input signal.
  • the input manager 524 in the first virtual machine 520 may receive a touch input from the first display 180a or the second display 180b.
  • the first virtualization machine 520 transmits information about a touch input related to a touch input from the first display 180a or the second display 180b to the second virtualization machine 530 or the third virtualization machine 520 . It may have a touch server 528 that transmits to machine 540 .
  • the touch server 528 in the first virtualization machine 520 transmits information about the touch input (Touch) to the second virtualization machine 530. ) can be transmitted.
  • the touch server 528 in the first virtual machine 520 may receive a touch input from the first display 180a or the second display 180b.
  • the first virtualization machine 520 includes a first call interface 521 that receives sensor data from the sensor device 760 in the vehicle 100 and a radio signal from the tuner 105 in the vehicle 100. , an input/output server interface 522 for transmitting sensor data or data corresponding to a radio signal received from the first call interface 521 to at least one of the second virtual machine 530 and the third virtual machine 540 . Accordingly, it is possible to efficiently use resources among a plurality of virtual machines.
  • the second virtual machine 530 and the third virtual machine 540 are input/output for receiving sensor data or data corresponding to a radio signal from the first call interface 521 in the first virtual machine 520.
  • Client interfaces 532 and 542 may be provided, respectively. Accordingly, it is possible to quickly share sensor data.
  • the second virtual machine 530 and the third virtual machine 540 do not perform data communication with the sensor device 760 in the vehicle 100 and the tuner 105 in the vehicle 100 . Accordingly, it is possible to efficiently use resources among a plurality of virtual machines.
  • the first virtualization machine 520 controls sensor data or data corresponding to a radio signal to be stored in the shared memory 508, and at least one of the second virtualization machine 530 and the third virtualization machine 540 may receive sensor data stored in the shared memory 508 or data corresponding to a radio signal. Accordingly, it is possible to quickly receive and process sensor data or data corresponding to a radio signal.
  • the first virtualization machine 520 to the second virtualization machine 530 or the third virtualization machine 540, provides a buffer index for the shared memory 508 in which sensor data or data corresponding to a radio signal is stored. transmission, and the second virtualization machine 530 or the third virtualization machine 540 may read data corresponding to sensor data or a radio signal stored in the shared memory 508 based on the received buffer index. Accordingly, it is possible to quickly share sensor data or data corresponding to a radio signal.
  • the first virtualization machine 520 receives wheel speed sensor data of the vehicle 100 through the first call interface 521, processes it, and converts the second virtualization machine 530 or the third virtualization machine ( At least one of 540), the processed wheel speed sensor data or speed information corresponding to the processed wheel speed sensor data may be transmitted through the input/output server interface 522. Accordingly, wheel speed sensor data of the vehicle 100 can be quickly shared.
  • the first virtualization machine 520 receives and processes the air conditioning data of the vehicle 100 through the first call interface 521 to generate the second virtualization machine 530 or the third virtualization machine 540. At least one of the processed air conditioning data or the internal temperature information of the vehicle 100 corresponding to the processed air conditioning data may be transmitted through the input/output server interface 522 . Accordingly, air conditioning data of the vehicle 100 can be quickly shared.
  • sensor data from the sensor device 760 in the vehicle 100 is received based on CAN communication, and the first call interface 521 in the first virtualization machine 520 in the processor 175 transmits USB data.
  • Bluetooth communication data can be further received. Accordingly, it is possible to quickly share data based on CAN communication.
  • FIG. 6 is a diagram illustrating another example of a system driven by a signal processing apparatus according to an embodiment of the present invention.
  • the processor 175 in the signal processing device 170 is a hypervisor ( 505), the first to third virtual machines 520 to 540 are executed, and the first virtual machine 520 in the processor 175 includes the second virtual machine 530 and the third virtual machine 540 ), the shared memory 508 based on the hypervisor 505 is controlled to be set for data transmission.
  • information on touch input may be exemplified as data. Accordingly, information on the touch input (Touch) is transmitted to the second virtual machine 530 or the third virtual machine 540, and eventually, a touch input to the first display 180a or the second display 180b. (Touch) processing can be performed quickly and accurately. In addition, even if the number of driven virtual machines increases, processing for touch inputs (Touch) can be performed quickly and accurately.
  • image data may be exemplified as data. Accordingly, an image can be displayed on the first display 180a or the second display 180b.
  • the same image data when shared in the shared memory 508, the same image may be synchronized and displayed on a plurality of displays 180a to 180b in the vehicle.
  • data may include CAN communication data, audio data, radio data, USB data, wireless communication data, location information data, and the like. Accordingly, information on corresponding data can be displayed on the first display 180a or the second display 180b.
  • the legacy virtualization machine 510 transmits memory data from the memory 140 or Ethernet data through Ethernet communication using the shared memory 508 based on the hypervisor 505. , may be transmitted to the second virtual machine 530 and the third virtual machine 540. Accordingly, information corresponding to memory data or Ethernet data can be displayed on the first display 180a or the second display 180b.
  • the input/output server interface 522 in the first virtual machine 520 in the system 500b of FIG. 6, unlike FIG. 5, may include a display layer server 529 and a touch server 528.
  • the first virtualization machine 520 of FIG. 6 includes a system manager for overall system control, a vehicle information manager for vehicle information management, and an audio manager for audio control. , a radio manager for radio control, and the like may be further provided.
  • the input/output server interface 522 in the first virtual machine 520 in the system 500b of FIG. 6 includes a GNSS server for input/output of GPS information, a Bluetooth server for input/output of Bluetooth, a Wi-Fi server for input/output via Wi-Fi, and a camera.
  • a camera server for data input/output may be further included.
  • FIG. 7 is a diagram showing another example of a system driven by a signal processing apparatus according to an embodiment of the present invention.
  • a system 500c driven by the processor 175 in the signal processing device 170 of FIG. 7 is almost similar to the system 500b of FIG. 6 .
  • the processor 175 of FIG. 7 executes the first to third virtual machines 520 to 540 on the hypervisor 505 in the processor 175 .
  • the display layer server 529 and the touch server 528 may be provided and executed outside the input/output server interface 522 and within the first virtual machine 520 .
  • a GNSS server for input and output of GPS information a Bluetooth server for input and output of Bluetooth, a Wi-Fi server for input and output of Wi-Fi, a camera server for input and output of camera data, etc. are provided outside the input/output server interface 522, It may be provided and executed in the first virtualization machine 520 .
  • a display manager 527, a display layer server 529, an input manager 524, and a touch server 528 may be provided and executed.
  • the input/output server interface 522 in the first virtual machine 520 in the system 500b of FIG. 6, unlike FIG. 5, may include a display layer server 529 and a touch server 528.
  • FIG. 8 to 9B are views referred to in the description of FIG. 5 .
  • FIG. 8 shows that the first to third virtual machines 520 to 540 are executed on the hypervisor 505 in the processor 175 in the system 500 according to the embodiment of the present invention, and the processor ( 175) to set the shared memory 508 based on the hypervisor 505 to the second virtual machine 530 and the third virtual machine 540 for the same data transmission. exemplify control.
  • the same image can be synchronized and displayed on the plurality of displays 180a to 180b in the vehicle.
  • the first virtualization machine 520 in the processor 175 transmits the data processed by the first virtualization machine 520 to another virtualization machine
  • the number of memories corresponding to the number of virtualization machines is not allocated.
  • one shared memory 508 can be used. Accordingly, instead of 1:1 data communication between virtual machines, 1:N data communication is possible using the shared memory 508 .
  • the first virtualization machine 520 in the processor 175 may include an input/output server interface 522 and a security manager 526 .
  • the second virtual machine 530 and the third virtual machine 540 may include input/output client interfaces 532 and 542, respectively. Accordingly, it is possible to perform high-speed data communication between a plurality of virtual machines using the input/output server interface 522 and the input/output client interfaces 532 and 542 .
  • the input/output server interface 522 in the first virtual machine 520 receives the same data transfer request from each of the input/output client interfaces 532 and 542 in the second virtual machine 530 and the third virtual machine 540, Based on this, shared data may be transmitted to the shared memory 508 through the security manager 526 .
  • 9A illustrates a more detailed diagram of shared data transmission.
  • the input/output server interface 522 in the first virtual machine 520 transmits a request for allocation of the shared memory 508 to the security manager 526 (S1).
  • the security manager 526 may allocate the shared memory 508 using the hypervisor 505 (S2) and record shared data in the shared memory 508.
  • the I/O client interfaces 532 and 542 may transmit a connection request to the I/O server interface 522 after allocating the shared memory 508 (S3).
  • the I/O server interface 522 after allocating the shared memory 508, transmits information about the shared memory 508 including key data to the I/O client interfaces 532 and 542 (S4).
  • the key data at this time may be private key data.
  • the input/output server interface 522 in the first virtualization machine 520 controls to generate a command queue for command or event processing, separate from data, for distributed processing control between virtualization machines. (S5).
  • a command queue is created in the command queue buffer 504 in the hypervisor 505 under the control of the input/output server interface 522.
  • each of the input/output client interfaces 532 and 542 accesses the command queue buffer 504 and receives the created command queue or information about the command queue (S6).
  • the generated command queues may be the same.
  • command queues may be transmitted to the respective input/output client interfaces 532 and 542 .
  • each of the input/output client interfaces 532 and 542 accesses the shared memory 508 based on the received key data (S5), and transfers the shared data to the shared memory 508. It can be copied or read from (S7).
  • the input/output client interfaces 532 and 542 access the shared memory 508 based on the same command queue and the same key data (S5 ), the shared data can be copied or read from the shared memory 508.
  • the shared memory 508 can be accessed by the second virtualization machine 530 and the third virtualization machine 540, and eventually, shared data can be shared.
  • the shared data is image data
  • the second virtual machine 530 and the third virtual machine 540 share the image data, and eventually the plurality of displays 180a to 180b in the vehicle share the same. Images can be synchronized and displayed.
  • FIG. 9B by the system 500 of FIG. 9A, the second virtualization machine 530 displays the image data received through the shared memory 508 on the first display 180a, and the third virtualization machine 540 ) illustrates displaying image data received through the shared memory 508 on the second display 180b.
  • an image 905a displayed on the first display 180a is synchronized with an image 905b displayed on the second display 180b, and the same images 905a and 905b are displayed at time T1, respectively.
  • the image data processed by the first virtualization machine 520 in the processor 175 is transmitted to the second virtualization machine 530 and the third virtualization machine 540 through the shared memory 508, and the image data Based on this, the first image 905a displayed on the first display 180a and the second image 905b displayed on the second display 180b may be identical to each other. Accordingly, the same image can be synchronized and displayed on the plurality of displays 180a to 180b in the vehicle.
  • FIGS. 10A and 10B are diagrams for explaining a signal processing device related to the present invention.
  • FIG. 10A shows an example of a signal processing device related to the present invention.
  • a signal processing apparatus 170x related to the present invention may execute a plurality of virtual machines MAax and MAbx.
  • a plurality of virtual machines may use a remote procedure call (RPC) based on network communication for service use.
  • RPC remote procedure call
  • the second virtualization machine (MAax) executes the caller (RCA) for service use of the remote procedure call.
  • the plurality of virtual machines MAax and MAbx may include network stacks NSTaa and NSTab that convert network data into electrical signals, respectively.
  • the second virtualization machine (MAax) receives a request from the caller (RCA), serializes it, and provides the packing unit (Pkaa) to the network stack (NSTaa), and receives a response from the network stack (NSTaa) and reverses it.
  • An unpacking unit (UPkaa) that serializes and provides the data to a caller (RCA) and a processor (PNaa) using a network may be provided.
  • the first virtualization machine (MAbx) receives a request from the network stack (NSTab), deserializes it, and unpacks the unpacking unit (UPkab) to provide it to the called party (RCE), and the response from the called party (RCE). It may include a packing unit (Pkab) that receives, serializes, and provides the data to the network stack (NSTab), and a processor (PNab) that uses the network.
  • Pkab packing unit
  • NSTab network stack
  • PNab processor
  • the signal processing device 170x of the drawing since a remote procedure call based on network communication is used, if a network is available, it can be used.
  • 10B is a diagram for explaining another example of a signal processing device related to the present invention.
  • a signal processing apparatus 170y related to the present invention may execute a hypervisor (HPV) having a plurality of virtual machines (MAay and MAby) and a shared memory (SHy).
  • HPV hypervisor
  • MAay and MAby virtual machines
  • SHy shared memory
  • a plurality of virtual machines may use a remote procedure call (RPC) based on network communication for service use.
  • RPC remote procedure call
  • a first virtual machine (MAby) among a plurality of virtual machines (MAay, MAby) executes a callee (RCE) for a remote procedure call
  • a second virtual machine (RCE) among a plurality of virtual machines (MAay, MAby) (MAay) implements the caller (RCA) for remote procedure calls.
  • each of the plurality of virtual machines MAay and MAby may include network stacks NSTaa and NSTab that convert network data into electrical signals.
  • the second virtualization machine (MAay) receives a request from the caller (RCA), serializes it and provides it to the network stack (NSTaa), and receives a response from the network stack (NSTaa) and reverses the packing unit (Pkaa).
  • An unpacking unit (UPkaa) serialized and provided to the caller (RCA), a processor (PNaa) using a network, and a shared memory driver (SHMba) for driving the shared memory (SHy) may be provided.
  • the first virtualization machine receives a request from the network stack (NSTab), deserializes the request, and unpacks the unpacking unit (UPkab) to provide it to the called party (RCE), and the response from the called party (RCE). It may include a packing unit (Pkab) that receives and serializes data and provides it to the network stack (NSTab), a processor (PNab) using the network, and a shared memory driver (SHMbb) for driving the shared memory (SHy).
  • Pkab packing unit
  • PNab processor
  • SHMbb shared memory driver
  • the hypervisor HPV having the shared memory SHy is used, instead of converting into an electrical signal and transmitting network data through a physical channel, the shared memory SHy ) to transmit network data.
  • the signal processing device 170y uses a remote procedure call based on network communication, it can be used if the network is available. However, like the signal processing device 170x of FIG. 10A , the signal processing device 170y has the disadvantage that a remote procedure call cannot be used before the network is activated by booting or the like, and the overhead coming from the network layer ( overhead) can be an issue.
  • a mutual sharing area (IVS) for remote procedure call is set in a shared memory and a method of using it is proposed. That is, we propose a method using a lightweight remote procedure call (RPC). This will be described with reference to FIG. 11 below.
  • FIG. 11 is a diagram illustrating an internal operation of a signal processing apparatus according to an embodiment of the present invention.
  • a signal processing apparatus 170m includes a processor 175 that performs signal processing for a display mounted on a vehicle, and the processor 175 is a hypervisor ( HHV) and executes a plurality of virtual machines (VMA, VMB) on the hypervisor (HHV).
  • HHV hypervisor
  • VMA, VMB virtual machines
  • VMA virtual machines
  • VMB virtual machine
  • VMA virtual machine
  • RPC remote procedure calls
  • SMR shared memory
  • HHV hypervisor
  • IVS mutual sharing area
  • the mutual sharing area may be named as an Inter-VM Stack Frame, as shown in the drawing.
  • the first virtualization machine provides a first virtualization machine (VMB) for access to the callee (RCE) receiving data corresponding to the caller (RCA) of the second virtualization machine (VMA) and the mutual sharing area (IVS). Execute the call interface (eRCb).
  • the first virtualization machine executes the called party (RCE) for providing remote procedure call service and the first call interface (eRCb) for access to the mutual sharing area (IVS).
  • the second virtualization machine executes a caller (RCA) for remote procedure call and a second call interface (eRCa) for access to the mutual sharing area (IVS).
  • a caller RCA
  • eRCa second call interface
  • the second virtualization machine executes the caller (RCA) for service use of remote procedure call and the second call interface (eRCa) for access to the mutual sharing area (IVS).
  • VMA, VMB virtual machines
  • VMA, VMB virtual machines
  • the call interfaces of the first call interface eRCb and the second call interface eRCa may be called Embedded Virtualization system RPC.
  • the signal processing apparatus 170m executes each call interface (eRCa, eRCb) in each virtual machine (VMA, VMB).
  • VMB may further execute the first shared memory driver (SMDb) for driving the shared memory (SMR).
  • SMDb shared memory driver
  • VMA virtualization machine
  • SMR shared memory driver
  • a host driver (HD) and a shared memory (SMR) may be executed in the hypervisor (HHV).
  • a control page table (CPT), an RPC control page, a mutual share area (IVS), and a call storage area (RSM) can be executed or configured.
  • the call storage area may also be named RPC Shared Memory.
  • the host driver (HD) may create a shared memory (SMR) for remote procedure call.
  • the host driver (HD) can create a control page table (CPT).
  • the shared memory drivers SMDa and SMDb of each of the virtual machines VMA and VMB may control memory allocation, release, area creation, and the like of the shared memory SMR.
  • the first call interface (eRCb) or the second call interface (eRCa) may provide a remote procedure call method through the shared memory (SMR).
  • the first call interface (eRCb) or the second call interface (eRCa) may generate or manage an RPC control page.
  • the first call interface (eRCb) or the second call interface (eRCa) may create or manage a remote procedure call channel including an IVS and a call storage area (RSM) for each caller.
  • RSM call storage area
  • an RPC call by the caller RCA may be performed by writing and reading information in the mutual sharing area IVS through the second call interface eRCa.
  • Parameter data transmitted by the caller (RCA) may be copied to the mutual sharing area (IVS) as it is without serialization together with meta data.
  • parameter data existing in the call storage area RSM is transferred as a pointer without copying.
  • the second call interface (eRCa) in the second virtualization machine (VMA) records call-related information in the mutual sharing area (IVS), notifies the first virtualization machine (VMB), and the first virtualization machine ( VMB) may receive data within the mutual sharing area (IVS). Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) in the first virtualization machine (VMB) records the processed result data based on the received data in the mutual sharing area (IVS), and notifies the second virtualization machine (VMA), , the second virtualization machine (VMA) may receive result data recorded in the mutual sharing area (IVS). Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface eRCb in the first virtual machine VMB or the second call interface eRCa in the second virtual machine VMA shares data exceeding the capacity of the mutual sharing area IVS. It can be controlled to be stored in a separate area RSM in the memory SMR. Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the second call interface eRCa controls copying of the parameter data and meta data to the mutual sharing area IVS in the case of parameter data transmitted by the caller RCA, and in case of a pointer parameter, data corresponding to the pointer. can be controlled to be transferred to the call storage area (RSM) in the shared memory (SMR). Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) or the second call interface (eRCa) may create or manage the control page (RCP) in the shared memory (SMR) or create or manage the mutual sharing area (IVS). there is. Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) or the second call interface (eRCa) may control to create or delete a remote procedure call channel including a mutual sharing area (IVS) and a call storage area (RSM). Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • VMA virtual machines
  • VMB virtual machines
  • VMA virtual machines
  • VMB call storage area
  • the first call interface eRCb or the second call interface eRCa may control to create or delete the control page RCP through the host driver HD. Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) or the second call interface (eRCa) may control to generate the number of control pages (RCP) corresponding to the number of remote procedure call related service providers. Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) or the second call interface (eRCa) may control to create a number of remote procedure call channels corresponding to the number of remote procedure call related service providers. Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) or the second call interface (eRCa) controls to store data having a size exceeding the mutual sharing area (IVS) in the call storage area (RSM), and controls the data to be stored in the call storage area (RSM). ) can be controlled to be recorded in the mutual sharing area (IVS). Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • the first call interface (eRCb) or the second call interface (eRCa) controls to store data having a size exceeding the mutual sharing area (IVS) in the call storage area (RSM), and controls the data to be stored in the call storage area (RSM). ) can be controlled to be recorded in the mutual sharing area (IVS). Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • FIG. 12 to 16d are views referred to in the description of FIG. 11 .
  • FIG. 12 is a diagram referenced for description of an internal operation of the shared memory of FIG. 11 .
  • a control page exists in a shared memory (SMR) and corresponds to a callee (RCE) that is a remote procedure call service provider.
  • control page (RCP), the first call interface (eRCb) through the host driver (evRPC host driver) (HD), the remote procedure call channel consisting of the mutual sharing area (IVS) and the call storage area (RSM) Can be created or removed.
  • control page RCP enables the first call interface eRCb to allocate or return memory from the call storage area RSM through the host driver HD.
  • the remote procedure call channel is composed of a mutual sharing area (IVS) and a call storage area (RSM), and corresponds to a caller (RCA) as a remote procedure call service user.
  • IVS mutual sharing area
  • RSM call storage area
  • the mutual sharing area (IVS) is one of the components of the remote procedure call channel.
  • the first call interface (eRCb) may record the requested remote procedure call information and result information in the mutual sharing area (IVS) and notify the other party through the mutual sharing area (IVS).
  • the remote procedure call information is object and request related information, and may include, for example, phone number query and object name information.
  • Result information may include, for example, phone number information.
  • the call storage area is one of the components of the remote procedure call channel, and is shared by the called party (RCE) and the calling party (RCA).
  • the call storage area (RSM) is used, for example, when the size of data required for remote procedure calls is large.
  • the screen capture data has a relatively large data size.
  • a memory may be allocated to the call storage area RSM, screen capture data may be stored, and the stored address may be recorded and transmitted to the mutual sharing area IVS. Accordingly, the side requesting the screen capture may access the corresponding memory and use the screen capture data.
  • VMB the first virtualization machine
  • RSM call storage area
  • IVS mutual sharing area
  • screen capture data can be easily and quickly transferred from the second virtual machine (VMA) to the first virtual machine (VMB) by using the call storage area (RSM) and the mutual sharing area (IVS).
  • VMA virtual machines
  • VMB mutual sharing area
  • IVS mutual sharing area
  • VMA, VMB it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • 13A is a diagram referenced to describe registration and deletion of a remote procedure call service.
  • the host driver HD creates a control page table CPT in the call storage area RSM (STa1).
  • the first call interface (eRCb) on the side of the called party (RCE) brings the address of the control page table (CPT) through the first shared memory driver (SMDb) (STa2).
  • the first call interface (eRCb) records the remote procedure call requested for registration from the called party (RCE) in the remote procedure call table.
  • the first call interface (eRCb) requests generation of the remote procedure call control page (RCP) through the control page table (CPT).
  • the host driver (HD) creates a control page (RCP) in the call storage area (RSM) and records related information in the control page table (CPT).
  • RCP control page
  • CPT control page table
  • a deletion request is requested through the control page table (CPT), and the host driver (HD) deletes the control page (RCP) and deletes the control page table (CPT) according to this request. update
  • the first virtualization machine receives data on the control page table (CPT) in the shared memory (SMR) and, based on the received data on the control page table (CPT), makes a first remote procedure call. service can be registered.
  • 13B is a diagram referenced to explain creation and deletion of a remote procedure call channel.
  • the remote procedure caller (RCA)-side second call interface (eRCa) retrieves the control page (RCP) address through the control page table (CPT) (STb2).
  • the second call interface (eRCa) on the remote procedure caller (RCA) side requests creation of a remote procedure call channel including a mutual sharing area (IVS) and a call storage area (RSM) through the control page (RCP). (STb3).
  • the host driver (HD) creates the mutual sharing area (IVS) and the call storage area (RSM), and records the corresponding information in the control page (RCP) (STb4).
  • the first call interface (eRCb) on the side of the called party (RCE) brings the channel information generated in the control page (RCP) (STb5).
  • the first call interface (eRCb) on the called party (RCE) side notifies the creation of the channel. and receive channel information generated in the control page (RCP).
  • the process is the same as the creation process, but the deletion of the remote procedure call channel is requested through the control page (RCP), and the host driver (HD) deletes the corresponding remote procedure call channel. Delete and update the control page (RCP).
  • the first call interface (eRCb) on the called party (RCE) side which is the server side of the remote procedure call, brings the control page (RCP) channel information deleted from the control page (RCP).
  • the second virtualization machine requests the shared memory (SMR) to create a remote procedure call channel including the mutual shared area (IVS) and the call storage area (RSM) in the shared memory (SMR), and creates the shared memory (SMR).
  • VMA virtualization machine
  • SMR shared memory
  • IVS mutual shared area
  • RSM call storage area
  • SMR shared memory
  • 13C is a diagram referenced to describe a remote procedure call in a first mode.
  • the first mode is a remote procedure call in a normal mode, and the size of data corresponding to the remote procedure call is equal to or less than the capacity of the mutual sharing area (IVS).
  • IVS mutual sharing area
  • the caller RCA requests a remote procedure call to the second call interface eRCa (STc1).
  • the second call interface (eRCa) on the side of the remote procedure caller (RCA) records the call-related information in the mutual sharing area (IVS) and requests a call (STc2).
  • the call-related information may include a function identifier (unique number or string), the number of function call parameters, an offset of the first parameter, or a function parameter.
  • the first calling interface (eRCb) on the side of the called party (RCE) receives the call request, reads information from the mutual sharing area (IVS), calls it from the remote procedure call table, brings function information, and Call the function with the argument recorded in (IVS) (STc3).
  • the address of the return value area of the mutual sharing area (IVS) is provided together, and the callee (RCE) can directly store the return value here.
  • the first call interface (eRCb) on the called party (RCE) side notifies the completion of the call through the mutual sharing area (IVS), and the second caller (RCA) side that performed the remote procedure call
  • the call interface eRCa notifies the remote procedure caller RCA (STc4).
  • the remote procedure caller (RCA) is blocked on the remote procedure call request until a call completion is received and returned upon receipt of a call completion notification.
  • the remote procedure call request of the remote procedure caller (RCA) is returned immediately, and the result is delivered through a separate context when the call completion notification is received.
  • VMA virtual machines
  • 13D is a diagram referenced to describe a remote procedure call in the second mode.
  • the second mode is a remote procedure call in a normal mode, and a case in which the size of data corresponding to the remote procedure call exceeds the capacity of the mutual sharing area (IVS) is exemplified.
  • IVS mutual sharing area
  • the remote procedure caller requests memory allocation from the second call interface (eRCa) (STd1).
  • the second call interface (eRCa) on the side of the remote procedure caller (RCA) requests memory allocation to the call storage area (RSM) of the corresponding channel through the control page (RCP) (STd2).
  • the host driver (HD) allocates memory to the call storage area (RSM) of the corresponding channel and returns the address (STd3).
  • the remote procedure caller (RCA) directly writes data to the allocated memory (STd4).
  • the remote procedure caller requests a remote procedure call to the second call interface (eRCa), and the second call interface (eRCa) processes the remote procedure call request as in the previous case.
  • the function argument is the memory address of the call storage area (RSM) (STd5).
  • the first call interface (eRCb) on the called party (RCE) side receives a call request, reads information from the call storage area (RSM) and the mutual sharing area (IVS), and makes a remote procedure call.
  • RSM call storage area
  • IVS mutual sharing area
  • the address of the return value area of the mutual sharing area (IVS) is provided together, and the callee (RCE) can directly store the return value here.
  • the first call interface (eRCb) on the called party (RCE) side notifies the completion of the call through the mutual sharing area (IVS), and the second caller (RCA) side that performed the remote procedure call
  • the calling interface (eRCa) notifies the remote procedure caller (RCA) upon receipt of the call completion.
  • 14A and 14B are diagrams illustrating that a remote procedure call is performed after booting.
  • FIG. 14A illustrates transmission of data for a screen display service between a server virtualization machine 520 and a guest virtualization machine 530 using a network.
  • the guest virtual machine 530 transmits data to the server virtual machine 520 using a network.
  • the guest virtual machine 530 may transmit data to the server virtual machine 520 after all network stacks are loaded.
  • FIG. 14B illustrates transmission of data for a screen display service between a server virtualization machine 520 and a guest virtualization machine 530 using a mutual sharing area (IVS) and call interfaces (eRCa and eRCb).
  • IVS mutual sharing area
  • eRCa and eRCb call interfaces
  • the guest virtual machine 530 creates an IVS and call interfaces eRCa and eRCb. By using, data may be transmitted to the server virtualization machine 520 .
  • the guest virtual machine 530 may transmit data to the server virtual machine 520 using the mutual sharing area (IVS) and call interfaces (eRCa, eRCb). there is.
  • IVS mutual sharing area
  • eRCa, eRCb call interfaces
  • the guest virtualization machine 530 of FIG. 14B corresponds to the second virtualization machine (VMA) of FIG. 11 to 13D
  • the server virtualization machine 520 of FIG. 14B corresponds to the first virtualization machine of FIG. 11 to 13D. It can correspond to the machine (VMB).
  • the remote procedure call of the second virtual machine (VMA), the first virtual machine (VMB), immediately after booting uses the mutual sharing area (IVS) to transfer data to the second virtual machine (VMA).
  • transmission can be controlled. Accordingly, it is possible to efficiently use resources between a plurality of virtual machines (VMA, VMB). In particular, it is possible to reduce the call and response delay time when calling a remote procedure between a plurality of virtual machines (VMA, VMB).
  • 14c and 14d are diagrams illustrating that a remote procedure call is performed when sensing data is repeatedly received.
  • FIG. 14C illustrates an example of a system for receiving repetitive sensing data.
  • 14D is a diagram illustrating a system according to an embodiment of the present invention.
  • the second virtualization machine 530 operates for the first display 180a, and the processor 175 further executes the third virtualization machine 540 for the second display 180b, and the second virtualization machine 530
  • the machine 530 requests music play information from the third virtual machine 530 by using the second mutual sharing area IVS in the shared memory SMR, and records the information recorded in the second mutual sharing area IVS.
  • control may be performed to display the music play information on the first display 180a. Transmission of music reproduction information will be described with reference to FIGS. 15A to 15D.
  • 15A to 15D are diagrams referenced to explain a case in which music reproduction information is requested from an AVN display in a cluster display.
  • 15A illustrates querying whether or not to play music from the second virtualization machine 530 operating for the first display 180a to the third virtualization machine 540 operating for the second display 180b. .
  • the human machine interface (HMI) in the second virtualization machine 530 transfers a call related to playback to a media service running in the third virtualization machine 540 through a remote procedure call (STf1). .
  • 15B illustrates a request for periodic update of reproduction information from the second virtual machine 530 to the third virtual machine 540.
  • the human machine interface (HMI) in the second virtualization machine 530 transfers a call for periodic update of playback information to a media service running in the third virtualization machine 540 through a remote procedure call. (STf2).
  • 15C illustrates updating periodic play information from the third virtual machine 540 to the second virtual machine 530 .
  • the media service running in the third virtualization machine 540 forwards a call to update periodic play information to a human machine interface (HMI) in the second virtualization machine 530 through a remote procedure call. (STf3).
  • HMI human machine interface
  • FIG. 15D illustrates displaying a screen 1580 including map information 1590 and driving information 1592 as well as music play information 1594 on the first display 180a, which is a cluster display.
  • the second virtualization machine operates for the first display 180a
  • the processor 175 further executes a third virtualization machine for the second display 180b
  • the second virtualization machine (VMA) ) requests screen theme information to the third virtualization machine using the second mutual sharing area IVS in the shared memory SMR, receives the screen theme information recorded in the second mutual sharing area IVS, and , the screen theme information can be controlled to be displayed on the first display 180a.
  • the screen theme information will be described with reference to FIGS. 16A to 16D.
  • 16A to 16D are diagrams referenced to explain a case in which screen theme setting is performed on the cluster display 180a and the AVN display 108b.
  • 16A illustrates requesting screen theme information from the second virtualization machine 530 operating for the first display 180a to the third virtualization machine 540 operating for the second display 180b. .
  • the human machine interface (HMI) in the second virtualization machine 530 transfers a call related to screen theme information to a setting service executed in the third virtualization machine 540 through a remote procedure call (STg1 ).
  • HMI human machine interface
  • 16B illustrates notification of a screen theme change from the third virtualization machine 540 to the second virtualization machine 530 .
  • the setting service executed in the third virtualization machine 540 transfers a call for changing a screen theme to a human machine interface (HMI) in the second virtualization machine 530 through a remote procedure call ( STg2).
  • HMI human machine interface
  • STg2 remote procedure call
  • 16C illustrates that a screen 1580 including map information 1590, driving information 1592, and music play information 1594 is displayed on the first display 180a, which is a cluster display.
  • the screen 1580 is displayed according to the first screen theme mode.
  • FIG. 16D illustrates that a screen 1680 including map information 1690, driving information 1692, and music play information 1694 is displayed on the first display 180a, which is a cluster display.
  • the screen 1680 is displayed according to a second screen theme mode different from the first screen theme mode according to a screen theme change from the third virtualization machine 540 .

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mechanical Engineering (AREA)
  • Human Computer Interaction (AREA)
  • Fittings On The Vehicle Exterior For Carrying Loads, And Devices For Holding Or Mounting Articles (AREA)

Abstract

본 발명은 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치에 관한 것이다. 본 발명의 일 실시예에 따른 신호 처리 장치는, 차량에 장착되는 디스플레이를 위한 신호 처리를 수행하는 프로세서를 포함하며, 프로세서는, 프로세서 내의 하이퍼바이저 상에서, 복수의 가상화 머신을 실행하며, 복수의 가상화 머신 중 제1 가상화 머신과, 제2 가상화 머신은, 하이퍼바이저 내의 공유 메모리 내에 원격 절차 호출을 위한 상호 공유 영역을 공유하며, 제1 가상화 머신은, 제2 가상화 머신의 호출자에 대응하여 데이터를 수신하는 피호출자와, 상호 공유 영역으로의 억세스를 위한 제1 호출 인터페이스를 실행하고, 제2 가상화 머신은, 원격 절차 호출을 위한 호출자와, 상호 공유 영역으로의 억세스를 위한 제2 호출 인터페이스를 실행한다. 이에 의해, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다.

Description

신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
본 발명은 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치에 관한 것이며, 더욱 상세하게는 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있는 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치에 관한 것이다.
차량은 탑승하는 사용자가 원하는 방향으로 이동시키는 장치이다. 대표적으로 자동차를 예를 들 수 있다.
한편, 차량을 이용하는 사용자의 편의를 위해, 차량 내부에 차량용 디스플레이 장치가 탑재되고 있다.
예를 들어, 클러스터 등에 디스플레이가 배치되어, 각 종 정보를 표시한다. 한편, 차량 주행 정보 등의 표시를 위해, 클러스터와 별도로, AVN(Audio Video Navigation) 디스플레이 등 다양한 디스플레이가 차량에 장착되는 추세이다.
이와 같이, 차량용 디스플레이 장치 내에 디스플레이의 개수가 증가할수록, 디스플레이를 위한 신호 처리가 복잡해지는 문제가 있다.
이를 위해, 차량용 디스플레이 장치는, 복수의 가상화 머신을 이용하여, 통합된 사용자 경험의 제공하기 위한 연구가 진행되고 있다.
한편, 복수의 가상화 머신 사이에서, 서비스의 이용을 위해, 네트워크 통신에 기반한 원격 절차 호출(Remote Procedure Call; RPC)이 사용된다.
그러나, 이러한 원격 절차 호출 방식은, 프로세서의 사용량을 증가시키고, 다른 목적의 네트워크 사용에 따른 응답 지연이 발생하는 문제가 있다. 나아가, 시스템 부팅 초기에 네트워크가 활성화되기 전에는, 원격 절차 호출의 사용이 불가능하다는 단점이 있다.
한편, 미국등록특허공보 US7941800호(이하, 선행 문헌이라 함)에는, 파이프 모드(pipe mode)로 동작하는 가상화 머신 버스를 통해 가상화 머신 사이에 데이터를 전송하는 것이 개시된다.
그러나, 선행 문헌에서의 파이프 모드를 사용하여도, 시스템의 리소스를 효율적으로 사용하지 못하고, 신속한 상호 작용이 수행되지 못하는 단점이 있다.
본 발명의 목적은, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있는 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치를 제공함에 있다.
본 발명의 다른 목적은, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있는 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치를 제공함에 있다.
본 발명의 또 다른 목적은, 데이터 공유와 원격 절차 호출을 통합할 수 있는 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치를 제공함에 있다.
한편, 본 발명의 다른 목적은, 가상화 머신의 개수가 증가되더라도, 가상화 머신 사이에 신속한 상호 작용을 구현할 수 있는 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치를 제공함에 있다.
상기 목적을 달성하기 위한 본 발명의 일 실시예에 따른 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치는, 차량에 장착되는 디스플레이를 위한 신호 처리를 수행하는 프로세서를 포함하며, 프로세서는, 프로세서 내의 하이퍼바이저 상에서, 복수의 가상화 머신을 실행하며, 복수의 가상화 머신 중 제1 가상화 머신과, 제2 가상화 머신은, 하이퍼바이저 내의 공유 메모리 내에 원격 절차 호출을 위한 상호 공유 영역을 공유하며, 제1 가상화 머신은, 제2 가상화 머신의 호출자에 대응하여 데이터를 수신하는 피호출자와, 상호 공유 영역으로의 억세스를 위한 제1 호출 인터페이스를 실행하고, 제2 가상화 머신은, 원격 절차 호출을 위한 호출자와, 상호 공유 영역으로의 억세스를 위한 제2 호출 인터페이스를 실행한다.
한편, 제2 가상화 머신은, 상호 공유 영역에 호출과 관련한 정보를 기록하고, 제1 가상화 머신에 통보하며, 제1 가상화 머신은, 상호 공유 영역 내의 데이터를 수신할 수 있다.
한편, 제1 가상화 머신은, 수신된 데이터에 기초하여 처리된 결과 데이터를 상호 공유 영역 내에 기록하고, 제2 가상화 머신에 통보하고, 제2 가상화 머신은, 상호 공유 영역에 기록된 결과 데이터를 수신할 수 있다.
한편, 제1 가상화 머신 또는 제2 가상화 머신은, 상호 공유 영역의 용량을 초과하는 데이터를, 공유 메모리 내의 별도 영역에 저장하도록 제어할 수 있다.
한편, 제2 호출 인터페이스는, 호출자가 전달한 파라미터 데이터인 경우, 파라미터 데이터와 메타 데이터를 상호 공유 영역으로 복사하도록 제어하고, 포인터 파라미터인 경우, 포인터에 대응하는 데이터를 공유 메모리 내의 호출 저장 영역에 전달하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 공유 메모리 내의 컨트롤 페이지를 생성 또는 관리하거나, 상호 공유 영역을 생성 또는 관리하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 공유 메모리 내의 컨트롤 페이지 테이블, 컨트롤 페이지를 통해, 공유 메모리 외부의 호스트 드라이버와 상호 작용하여, 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 호스트 드라이버를 통해, 컨트롤 페이지를 생성하거나 삭제하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 컨트롤 페이지를 생성하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 원격 절차 호출 채널을 생성하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 상호 공유 영역을 초과하는 사이즈의 데이터를, 호출 저장 영역에 저장하도록 제어하고, 호출 저장 영역의 주소를 상호 공유 영역에 기록하도록 제어할 수 있다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 상호 공유 영역을 초과하는 사이즈의 데이터를, 호출 저장 영역에 저장하도록 제어하고, 호출 저장 영역의 주소를 상호 공유 영역에 기록하도록 제어할 수 있다.
한편, 제1 호출 인터페이스는, 화면 쳐캡 데이터인 경우, 호출 저장 영역에 저장하도록 제어하고, 호출 저장 영역의 주소를 상호 공유 영역에 기록하도록 제어할 수 있다.
한편, 제1 가상화 머신은, 공유 메모리 내의 컨트롤 페이지 테이블에 대한 데이터를 수신하고, 수신된 컨트롤 페이지 테이블에 대한 데이터에 기초하여, 제1 원격 절차 호출 서비스를 등록할 수 있다.
한편, 제2 가상화 머신은, 공유 메모리 내에 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하도록 공유 메모리에 요청하고, 생성된 원격 절차 호출 채널에 대한 정보를 수신할 수 있다.
한편, 제1 가상화 머신은, 부팅 이후, 상호 공유 영역을 이용하여, 제2 가상화 머신으로 데이터가 전송되도록 제어할 수 있다.
한편, 제1 가상화 머신은, 센싱 데이터를 반복적으로 수신하며, 상호 공유 영역을 이용하여, 제2 가상화 머신으로 센싱 데이터가 전송되도록 제어할 수 있다.
한편, 제2 가상화 머신은 제1 디스플레이를 위해 동작하며, 프로세서는, 제2 디스플레이를 위해 제3 가상화 머신을 더 실행하며, 제2 가상화 머신은, 공유 메모리 내의 제2 상호 공유 영역을 이용하여, 음악 재생 정보를 제3 가상화 머신으로 요청하며, 제2 상호 공유 영역에 기록된 음악 재생 정보를 수신하여, 음악 재생 정보를 제1 디스플레이에 표시하도록 제어할 수 있다.
한편, 제2 가상화 머신은 제1 디스플레이를 위해 동작하며, 프로세서는, 제2 디스플레이를 위해 제3 가상화 머신을 더 실행하며, 제2 가상화 머신은, 공유 메모리 내의 제2 상호 공유 영역을 이용하여, 화면 테마 정보를 제3 가상화 머신으로 요청하며, 제2 상호 공유 영역에 기록된 화면 테마 정보를 수신하여, 화면 테마 정보를 제1 디스플레이에 표시하도록 제어할 수 있다.
본 발명의 일 실시예에 따른 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치는, 차량에 장착되는 디스플레이를 위한 신호 처리를 수행하는 프로세서를 포함하며, 프로세서는, 프로세서 내의 하이퍼바이저 상에서, 복수의 가상화 머신을 실행하며, 복수의 가상화 머신 중 제1 가상화 머신과, 제2 가상화 머신은, 하이퍼바이저 내의 공유 메모리 내에 원격 절차 호출을 위한 상호 공유 영역을 공유하며, 제1 가상화 머신은, 제2 가상화 머신의 호출자에 대응하여 데이터를 수신하는 피호출자와, 상호 공유 영역으로의 억세스를 위한 제1 호출 인터페이스를 실행하고, 제2 가상화 머신은, 원격 절차 호출을 위한 호출자와, 상호 공유 영역으로의 억세스를 위한 제2 호출 인터페이스를 실행한다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다. 또한, 데이터 공유와 원격 절차 호출을 통합할 수 있게 된다.
한편, 제2 가상화 머신은, 상호 공유 영역에 호출과 관련한 정보를 기록하고, 제1 가상화 머신에 통보하며, 제1 가상화 머신은, 상호 공유 영역 내의 데이터를 수신할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신은, 수신된 데이터에 기초하여 처리된 결과 데이터를 상호 공유 영역 내에 기록하고, 제2 가상화 머신에 통보하고, 제2 가상화 머신은, 상호 공유 영역에 기록된 결과 데이터를 수신할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신 또는 제2 가상화 머신은, 상호 공유 영역의 용량을 초과하는 데이터를, 공유 메모리 내의 별도 영역에 저장하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제2 호출 인터페이스는, 호출자가 전달한 파라미터 데이터인 경우, 파라미터 데이터와 메타 데이터를 상호 공유 영역으로 복사하도록 제어하고, 포인터 파라미터인 경우, 포인터에 대응하는 데이터를 공유 메모리 내의 호출 저장 영역에 전달하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 공유 메모리 내의 컨트롤 페이지를 생성 또는 관리하거나, 상호 공유 영역을 생성 또는 관리하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 공유 메모리 내의 컨트롤 페이지 테이블, 컨트롤 페이지를 통해, 공유 메모리 외부의 호스트 드라이버와 상호 작용하여, 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 호스트 드라이버를 통해, 컨트롤 페이지를 생성하거나 삭제하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 컨트롤 페이지를 생성하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 원격 절차 호출 채널을 생성하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 상호 공유 영역을 초과하는 사이즈의 데이터를, 호출 저장 영역에 저장하도록 제어하고, 호출 저장 영역의 주소를 상호 공유 영역에 기록하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스 또는 제2 호출 인터페이스는, 상호 공유 영역을 초과하는 사이즈의 데이터를, 호출 저장 영역에 저장하도록 제어하고, 호출 저장 영역의 주소를 상호 공유 영역에 기록하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스는, 화면 쳐캡 데이터인 경우, 호출 저장 영역에 저장하도록 제어하고, 호출 저장 영역의 주소를 상호 공유 영역에 기록하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신은, 공유 메모리 내의 컨트롤 페이지 테이블에 대한 데이터를 수신하고, 수신된 컨트롤 페이지 테이블에 대한 데이터에 기초하여, 제1 원격 절차 호출 서비스를 등록할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제2 가상화 머신은, 공유 메모리 내에 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하도록 공유 메모리에 요청하고, 생성된 원격 절차 호출 채널에 대한 정보를 수신할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신은, 부팅 이후, 상호 공유 영역을 이용하여, 제2 가상화 머신으로 데이터가 전송되도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신은, 센싱 데이터를 반복적으로 수신하며, 상호 공유 영역을 이용하여, 제2 가상화 머신으로 센싱 데이터가 전송되도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 센싱 데이터 전송시의 리소스를 효율적으로 사용할 수 있게 된다.
한편, 제2 가상화 머신은 제1 디스플레이를 위해 동작하며, 프로세서는, 제2 디스플레이를 위해 제3 가상화 머신을 더 실행하며, 제2 가상화 머신은, 공유 메모리 내의 제2 상호 공유 영역을 이용하여, 음악 재생 정보를 제3 가상화 머신으로 요청하며, 제2 상호 공유 영역에 기록된 음악 재생 정보를 수신하여, 음악 재생 정보를 제1 디스플레이에 표시하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 음악 재생 정보 전송시의 리소스를 효율적으로 사용할 수 있게 된다. 나아가, 가상화 머신의 개수가 증가되더라도, 가상화 머신 사이에 신속한 상호 작용을 구현할 수 있게 된다.
한편, 제2 가상화 머신은 제1 디스플레이를 위해 동작하며, 프로세서는, 제2 디스플레이를 위해 제3 가상화 머신을 더 실행하며, 제2 가상화 머신은, 공유 메모리 내의 제2 상호 공유 영역을 이용하여, 화면 테마 정보를 제3 가상화 머신으로 요청하며, 제2 상호 공유 영역에 기록된 화면 테마 정보를 수신하여, 화면 테마 정보를 제1 디스플레이에 표시하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 화면 테마 정보 전송시의 리소스를 효율적으로 사용할 수 있게 된다.
도 1a는 차량 외부 및 차량 내부의 일예를 도시한 도면이다.
도 1b는 차량 내부의 다른 예를 도시한 도면이다.
도 2는 본 발명의 실시예에 따른 차량용 디스플레이 장치의 외관을 도시한 도면이다.
도 3은 도 2의 차량용 디스플레이 장치의 내부 블록도의 일예를 예시한다.
도 4는 본 발명과 관련한 신호 처리 장치에서 구동되는 시스템을 도시한 도면이다.
도 5는 본 발명의 실시예에 따른 신호 처리 장치에서 구동되는 시스템의 일예를 도시한 도면이다.
도 6은 본 발명의 실시예에 따른 신호 처리 장치에서 구동되는 시스템의 다른 예를 도시한 도면이다.
도 7은 본 발명의 실시예에 따른 신호 처리 장치에서 구동되는 시스템의 또 다른 예를 도시한 도면이다.
도 8 내지 도 9b는 도 5의 설명에 참조되는 도면이다.
도 10a 내지 도 10b는 본 발명과 관련한 신호 처리 장치를 설명하는 도면이다.
도 11은 본 발명의 실시예에 따른 신호 처리 장치의 내부 동작을 설명하는 도면이다.
도 12 내지 도 16d는 도 11의 설명에 참조되는 도면이다.
이하에서는 도면을 참조하여 본 발명을 보다 상세하게 설명한다.
이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 단순히 본 명세서 작성의 용이함만이 고려되어 부여되는 것으로서, 그 자체로 특별히 중요한 의미 또는 역할을 부여하는 것은 아니다. 따라서, 상기 "모듈" 및 "부"는 서로 혼용되어 사용될 수도 있다.
도 1a는 차량 외부 및 차량 내부의 일예를 도시한 도면이다.
도면을 참조하면, 차량(200)은, 동력원에 의해 회전하는 복수의 바퀴(103FR,103FL,103RL,..), 차량(200)의 진행 방향을 조절하기 위한 스티어링휠(150)에 의해 동작한다.
한편, 차량(200)은, 차량 전방의 영상 획득을 위한 카메라(195) 등을 더 구비할 수 있다.
한편, 차량(200)은, 내부에 영상, 정보 등의 표시를 위한 복수의 디스플레이(180a,180b)를 구비할 수 있다.
도 1a에서는, 복수의 디스플레이(180a,180b)로, 클러스터 디스플레이(180a), AVN(Audio Video Navigation) 디스플레이(180b)를 예시한다. 그 외, HUD(Head Up Display) 등도 가능하다.
한편, AVN(Audio Video Navigation) 디스플레이(180b)는, 센터 정보 디스플레이(Center Information Dislpay)라 명명할 수도 있다.
한편, 본 명세서에서 기술되는 차량(200)은, 동력원으로서 엔진을 구비하는 차량, 동력원으로서 엔진과 전기 모터를 구비하는 하이브리드 차량, 동력원으로서 전기 모터를 구비하는 전기 차량 등을 모두 포함하는 개념일 수 있다.
도 1b는 차량 내부의 다른 예를 도시한 도면이다.
도면을 참조하면, 차량 내부에는, 클러스터 디스플레이(180a), AVN(Audio Video Navigation) 디스플레이(180b), 뒷 좌석 엔터네인먼트(Rear Seat Entertainment) 디스플레이(180c,180d), 룸미러 디스플레이(미도시) 등이 장착될 수 있다.
도 2는 본 발명의 실시예에 따른 차량용 디스플레이 장치의 외관을 도시한 도면이다.
본 발명의 실시예에 따른 차량용 디스플레이 장치(100)는, 복수의 디스플레이(180a~180b), 및 복수의 디스플레이(180a~180b)에 영상, 정보 등을 표시하기 위한 신호 처리를 수행하는 신호 처리 장치(170)를 구비할 수 있다.
복수의 디스플레이(180a~180b) 중 제1 디스플레이(180a)는, 주행 상태, 동작 정보 등의 표시를 위한 클러스터 디스플레이(180a)이고, 제2 디스플레이(180b)는, 챠량 운행 정보, 네비게이션 지도, 다양한 엔테테인먼트 정보 또는 영상의 표시를 위한 AVN(Audio Video Navigation) 디스플레이(180b)일 수 있다.
신호 처리 장치(170)는, 내부에 프로세서(175)를 구비하며, 프로세서(175) 내의 하이퍼바이저(505) 상에서, 제1 가상화 머신 내지 제3 가상화 머신(520~540)을 실행할 수 있다.
제2 가상화 머신(530)은 제1 디스플레이(180a)를 위해 동작하며, 제3 가상화 머신(540)은, 제2 디스플레이(180b)를 위해 동작할 수 있다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 차량(100) 내 센서 장치(760)로부터의 센서 데이터와, 차량(100) 내 튜너(105)로부터 라디오 신호를 수신하고, 수신된 센서 데이터 또는 라디오 신호에 대응하는 데이터를 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나로 전송한다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신 사이에서 호출과 응답 지연 시간을 단축할 수 있게 된다. 나아가, 복수의 가상화 머신의 운영체제가 다르더라도 센서 데이터를 신속하게 공유할 수 있게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 제2 가상화 머신(530) 및 제3 가상화 머신(540)으로, 동일한 데이터 전송을 위해, 하이퍼바이저(505) 기반의 공유 메모리(508)가 설정되도록 제어할 수 있다. 이에 따라, 차량 내의 제1 디스플레이(180a)와 제2 디스플레이(180b)에 동일한 정보 또는 동일한 영상을 동기화하여 표시할 수 있게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 데이터 분담 처리를 위해, 제2 가상화 머신(530)과 제3 가상화 머신(540)에 데이터의 적어도 일부를 공유한다. 이에 따라, 차량 내의 복수의 디스플레이를 위한 복수의 가상화 머신에서 데이터를 분담하여 처리할 수 있게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 차량의 휠 속도 센서 데이터를 수신하고, 처리하여, 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나로, 처리된 휠 속도 센서 데이터를 전송할 수 있다. 이에 따라, 차량의 휠 속도 센서 데이터를, 적어도 하나의 가상화 머신 등에 공유할 수 있게 된다.
한편, 본 발명의 실시예에 따른 차량용 디스플레이 장치(100)는, 주행 상태 정보, 간이 네비게이션 정보, 다양한 엔테테인먼트 정보 또는 영상의 표시를 위한 뒷 좌석 엔터네인먼트(Rear Seat Entertainment) 디스플레이(180c)를 더 구비할 수 있다.
신호 처리 장치(170)는, 프로세서(175) 내의 하이퍼바이저(505) 상에서, 제1 가상화 머신 내지 제3 가상화 머신(520~540) 외에 추가로 제4 가상화 머신(미도시)를 실행하여, RSE 디스플레이(180c)를 제어할 수 있다.
이에 따라, 하나의 신호 처리 장치(170)를 이용하여, 다양한 디스플레이(180a~180c)를 제어할 수 있게 된다.
한편, 복수의 디스플레이(180a~180c) 중 일부는, 리눅스 OS 기반 하에 동작하며, 다른 일부는 웹 OS 기반 하에 동작할 수 있다.
본 발명의 실시예에 따른 신호 처리 장치(170)는, 다양한 운영 체제(Operating system;OS) 하에 동작하는 복수의 디스플레이(180a~180b 또는 180a~180c) 중 어느 하나에서 터치 입력(Touch)이 있는 경우, 터치 입력에 대한 처리를 신속하고 정확하게 수행하도록 제어할 수 있다.
한편, 도 2에서는, 제1 디스플레이(180a)에, 차량 속도 인디케이터(212a), 차량 내부 온도 인디케이터(213a)가 표시되고, 제2 디스플레이(180b)에, 복수의 애플리케이션과 차량 속도 인디케이터(212b)와 차량 내부 온도 인디케이터(213b)를 포함하는 홈 화면(222)이 표시되고, 제3 디스플레이(180c)에, 복수의 애플리케이션과 차량 내부 온도 인디케이터(213c)를 포함하는 제2 홈 화면(222b)이 표시되는 것을 예시한다.
도 3은 본 발명의 실시예에 따른 차량용 디스플레이 장치의 내부 블록도의 일예를 예시한다.
도면을 참조하면, 본 발명의 실시예에 따른 차량용 디스플레이 장치(100)는, 입력부(110), 통신부(120), 인터페이스(130), 신호 처리 장치(170), 복수의 디스플레이(180a~180c), 오디오 출력부(185), 전원 공급부(190)를 구비할 수 있다.
입력부(110)는, 버튼 입력, 터치 입력 등을 위한 물리적인 버튼, 패드 등을 구비할 수 있다.
한편, 입력부(110)는, 디스플레이(180a,180b,180c)의 터치 입력을 센싱하기 위한 터치 센서(미도시)를 구비할 수 있다.
한편, 입력부(110)는, 사용자 음성 입력을 위한 마이크(미도시)를 구비할 수 있다.
통신부(120)는, 이동 단말기(800) 또는 서버(900)와 무선(wireless) 방식으로, 데이터를 교환할 수 있다.
특히, 통신부(120)는, 차량 운전자의 이동 단말기와, 무선으로 데이터를 교환할 수 있다. 무선 데이터 통신 방식으로는, 블루투스(Bluetooth), WiFi, WiFi Direct, APiX 등 다양한 데이터 통신 방식이 가능하다.
통신부(120)는, 이동 단말기(800) 또는 서버(900)로부터, 날씨 정보, 도로의 교통 상황 정보, 예를 들어, TPEG(Transport Protocol Expert Group) 정보를 수신할 수 있다. 이를 위해, 통신부(120)는, 이동 통신 모듈(미도시)를 구비할 수 있다.
인터페이스(130)는, ECU(770) 또는 센서 장치(760)로부터, 센서 정보 등을 수신하고, 수신한 정보를 신호 처리 장치(170)로 전송할 수 있다.
여기서, 센서 정보는, 차량 방향 정보, 차량 위치 정보(GPS 정보), 차량 각도 정보, 차량 속도 정보, 차량 가속도 정보, 차량 기울기 정보, 차량 전진/후진 정보, 배터리 정보, 연료 정보, 타이어 정보, 차량 램프 정보, 차량 내부 온도 정보, 차량 내부 습도 정보 중 적어도 하나를 포함할 수 있다.
이러한 센서 정보는, 헤딩 센서(heading sensor), 요 센서(yaw sensor), 자이로 센서(gyro sensor), 포지션 모듈(position module), 차량 전진/후진 센서, 휠 센서(wheel sensor), 차량 속도 센서, 차체 경사 감지센서, 배터리 센서, 연료 센서, 타이어 센서, 핸들 회전에 의한 스티어링 센서, 차량 내부 온도 센서, 차량 내부 습도 센서 등으로부터 획득될 수 있다. 한편, 포지션 모듈은, GPS 정보 수신을 위한 GPS 모듈을 포함할 수 있다.
한편, 인터페이스(130)는, 카메라(195) 또는 라이더(미도시) 등으로부터 차량 전방 영상 데이터, 차량 측방 영상 데이터, 차량 후방 영상 데이터, 차량 주변 장애물 거리 정보 등을 수신하고, 수신한 정보를 신호 처리 장치(170)로 전송할 수 있다.
오디오 출력부(185)는, 신호 처리 장치(170)로부터의 전기 신호를 오디오 신호로 변환하여 출력한다. 이를 위해, 스피커 등을 구비할 수 있다.
전원 공급부(190)는, 신호 처리 장치(170)의 제어에 의해, 각 구성요소들의 동작에 필요한 전원을 공급할 수 있다. 특히, 전원 공급부(190)는, 차량 내부의 배터리 등으로부터 전원을 공급받을 수 있다.
신호 처리 장치(170)는, 차량용 디스플레이 장치(100) 내의 각 유닛의 전반적인 동작을 제어한다.
한편, 신호 처리 장치(170)는, 시스템 온 칩(System On Chip,SOC)의 형태로 구현될 수 있다.
신호 처리 장치(170)는, 차량용 디스플레이(180a,180b,180c)를 위한 신호 처리를 수행하는 프로세서(175), 각종 데이터를 저장하는 제1 메모리(140a)와 제2 메모리(140b), 마이컴(135)을 구비할 수 있다.
제1 메모리(140a)는, 비휘발성 메모리로서, 대기 모드 또는 전원 오프시에도, 각 종 데이터를 저장할 수 있다.
예를 들어, 제1 메모리(140a)는, 대기 모드로의 진입에 기초하여, 복수의 가상화 머신(510~550) 중 어느 하나의 가상화 머신에서 실행되는 제1 애플리케이션에 대응하는 파일을 저장할 수 있다.
다른 예로, 제1 메모리(140a)는, 운영 체제(OS)를 저장할 수 있다.
한편, 제1 메모리(140a)는, 신호 처리 장치(170)의 처리 또는 제어를 위한 프로그램 등, 차량용 디스플레이 장치(100) 전반의 동작을 위한 다양한 데이터를 저장할 수 있다.
한편, 제2 메모리(140b)는, 휘발성 메모리로서, 대기 모드 또는 전원 오프시에 각 종 데이터가 지워지며, 액티브 모드에서, 일시적으로 데이터를 저장할 수 있다.
예를 들어, 제2 메모리(140b)는, 대기 모드에서 액티브 모드로 전환에 기초하여, 제1 메모리(140a)에 저장된 파일을 로딩할 수 있다.
다른 예로, 제2 메모리(140b)는, 대기 모드에서 액티브 모드로 전환에 기초하여, 제1 메모리(140a)에 저장된 운영 체제(OS)를 로딩할 수 있다.
한편, 프로세서(175)는, 하이퍼바이저(도 5의 505)를 구동할 수 있다.
한편, 프로세서(175)는, 프로세서(175) 내의 하이퍼바이저(도 5의 505) 상에서, 제1 가상화 머신 내지 제4 가상화 머신(520~550)을 실행할 수 있다.
한편, 프로세서(175)는, 이더넷 데이터를 수신하고 처리하는 레가시 가상화 머신(510)을 더 실행할 수 있다. 예를 들어, 레가시 가상화 머신은, 도 5와 같이, 프로세서(175) 내의 제1 가상화 머신(520)에서 실행될 수 있다.
제1 가상화 머신 내지 제3 가상화 머신(도 5의 520~550) 중 제1 가상화 머신(520)은, 서버 가상화 머신(Server Virtual Maschine)이라 명명할 수 있으며, 제2 가상화 머신 내지 제4 가상화 머신(530~550)은 게스트 가상화 머신(Guest Virtual Maschine)이라 명명할 수 있다.
이때, 제2 가상화 머신(530)은 제1 디스플레이(180a)를 위해 동작하며, 제3 가상화 머신(540)은, 제2 디스플레이(180b)를 위해 동작하며, 제4 가상화 머신(550)은, 제3 디스플레이(180c)를 위해 동작할 수 있다.
예를 들어, 프로세서(175) 내의 제1 가상화 머신(520)은, 차량 센서 데이터, 위치 정보 데이터, 카메라 영상 데이터, 오디오 데이터 또는 터치 입력 데이터를 수신하고, 처리 또는 가공하여 출력할 수 있다. 레가시 가상화 머신에서만 처리하는 데이터와, 제1 가상화 머신(520)에서 처리되는 데이터를 구분함으로써, 데이터 처리를 효율적으로 수행할 수 있게 된다. 특히, 제1 가상화 머신(520)에서 대부분의 데이터 처리를 수행함으로써, 1:N 방식의 데이터의 공유가 가능하게 된다.
다른 예로, 제1 가상화 머신(520)은, 제2 가상화 머신 내지 제4 가상화 머신(530~550)을 위해, CAN 통신 데이터, 오디오 데이터, 라디오 데이터, USB 데이터, 무선 통신 데이터를 직접 수신하고 처리할 수 있다.
그리고, 제1 가상화 머신(520)은, 처리된 데이터를 제2 가상화 머신 내지 제4 가상화 머신(530~550)으로 전송할 수 있다.
이에 따라, 제1 가상화 머신 내지 제4 가상화 머신(520~550) 중 제1 가상화 머신(520)만, 통신 데이터, 외부 입력 데이터를 수신하여, 신호 처리를 수행함으로써, 다른 가상화 머신에서의 신호 처리 부담이 경감되며, 1:N 데이터 통신이 가능하게 되어, 데이터 공유시의 동기화가 가능하게 된다.
한편, 제1 가상화 머신(520)은, 데이터의 일부를 제2 가상화 머신(530)으로 전달되도록 제1 공유 메모리(미도시)에 기록하고, 데이터의 다른 일부를 제3 가상화 머신으로 전달되도록 제1 공유 메모리(미도시)에 기록하며, 제2 가상화 머신(530)과 제3 가상화 머신(540)은, 각각 전달받은 데이터를 처리하여, 처리된 데이터가 제2 공유 메모리(미도시)에 기록되도록 제어한다.
이때의 데이터는, 영상 데이터, 오디오 데이터, 네비게이션 데이터, 또는 음성 인식 데이터 중 어느 하나일 수 있다.
한편, 제1 가상화 머신(520)은, 데이터의 또 다른 일부를 처리하여, 제2 공유 메모리(미도시)에 처리된 데이터가 기록되도록 제어할 수 있다. 즉, 제2 가상화 머신(530)과 제3 가상화 머신 외에 추가로 제1 가상화 머신(520)이 데이터 처리를 수행할 수 있다.
한편, 프로세서(175) 내에 제3 디스플레이(180c)를 위해 동작하는 제4 가상화 머신(550)이 실행되는 경우, 제1 가상화 머신(520)은, 데이터의 또 다른 일부를 제1 공유 메모리(미도시)에 기록하며, 제4 가상화 머신(550)은, 각각 전달받은 데이터를 처리하여, 처리된 데이터가 제2 공유 메모리(미도시)에 기록되도록 제어할 수 있다.
한편, 제1 가상화 머신(520)은, 제2 가상화 머신 내지 제4 가상화 머신(530~550)에서의 데이터의 분산 처리를 위한 각각의 커맨드 큐를 생성할 수 있다. 이에 따라, 복수의 가상화 머신에서 데이터를 분담하여 처리할 수 있게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 제2 가상화 머신 내지 제4 가상화 머신(530~550)에서 동일한 데이터를 공유하는 경우, 1개의 동일한 커맨드 큐를 생성할 수 있다. 이에 따라, 동일한 데이터를 동기화하여 공유할 수 있게 된다.
한편, 제1 가상화 머신(520)은, 데이터의 분산 처리를 위한 가상화 머신의 개수에 대응하는 커맨드 큐를 생성할 수 있다.
한편, 제1 가상화 머신(520)은, 데이터 분산 처리를 위해, 데이터의 적어도 일부를, 제2 가상화 머신 내지 제4 가상화 머신(530~550) 중 적어도 하나로 전송되도록 제어할 수 있다.
예를 들어, 제1 가상화 머신(520)은, 데이터의 적어도 일부를, 제2 가상화 머신 내지 제4 가상화 머신(530~550) 중 적어도 하나로 전송하기 위한 제1 공유 메모리(미도시)를 할당하고, 제2 가상화 머신(530) 또는 제3 가상화 머신(540)에서 처리된 영상 데이터는 제2 공유 메모리(미도시)에 기록될 수 있다.
한편, 제1 가상화 머신(520)은, 데이터를 공유 메모리(508)에 기록하여,제2 가상화 머신 내지 제4 가상화 머신(530~550)으로 동일한 데이터를 공유하도록 제어할 수 있다.
예를 들어, 제1 가상화 머신(520)은, 라디오 데이터 또는 무선 통신 데이터를 공유 메모리(508)에 기록하여, 제2 가상화 머신 내지 제4 가상화 머신(530~550)으로 동일한 데이터를 공유하도록 제어할 수 있다. 이에 따라, 1:N 방식의 데이터의 공유가 가능하게 된다.
결국, 제1 가상화 머신(520)에서 대부분의 데이터 처리를 수행함으로써, 1:N 방식의 데이터의 공유가 가능하게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 제2 가상화 머신 내지 제4 가상화 머신(530~550)으로, 동일한 데이터 전송을 위해, 하이퍼바이저(505) 기반의 공유 메모리(508)가 설정되도록 제어할 수 있다.
즉, 프로세서(175) 내의 제1 가상화 머신(520)은, 하이퍼바이저(505) 기반의 공유 메모리(508)를 이용하여, 제2 가상화 머신 내지 제4 가상화 머신(530~550)으로, 동일한 데이터를 동기화하여 전송할 수 있다. 이에 따라, 차량 내의 복수의 디스플레이(180a~180c)에서 동일한 영상을 동기화하여 표시할 수 있게 된다.
한편, 신호 처리 장치(170)는, 오디오 신호, 영상 신호, 데이터 신호 등 다양한 신호를 처리할 수 있다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 차량(100) 내 센서 장치(760)로부터의 센서 데이터와, 차량(100) 내 튜너(105)로부터 라디오 신호를 수신하고, 센서 데이터 또는 라디오 신호에 대응하는 데이터를 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나로 전송할 수 있다. 이에 따라, 센서 데이터 또는 라디오 신호에 대응하는 데이터를 신속하게 공유할 수 있게 된다.
도 4는 본 발명과 관련한 신호 처리 장치에서 구동되는 시스템을 도시한 도면이다.
도면을 참조하면, 도 4는 클러스터 디스플레이(180a)와 AVN 디스플레이(180b)를 위해, 가상화 머신이 각각 사용되는 것을 예시하는 도면이다.
도 4의 신호 처리 장치에서 구동되는 시스템(400)은, 프로세서(175) 내의 하이퍼바이저(405) 상에서, 클러스터 가상화 머신(430), AVN 가상화 머신(440)이 실행되는 것을 예시한다.
한편, 도 4의 신호 처리 장치에서 구동되는 시스템(400)은, 프로세서(175) 내의 하이퍼바이저(405) 상에서, 레가시(legacy) 가상화 머신(410)도 실행되는 것을 예시한다.
레가시(legacy) 가상화 머신(410)은, 메모리(140)와의 데이터 통신을 위한 인터페이스(412), 이더넷 통신을 위한 인터페이스(413)을 구비한다.
한편, 클러스터 가상화 머신(430)은, CAN 통신을 위한 인터페이스(431), 레가시(legacy) 가상화 머신(410)의 인터페이스(412)와의 통신을 위한 인터페이스(432), 레가시(legacy) 가상화 머신(410)의 인터페이스(413)와의 통신을 위한 인터페이스(433)를 구비할 수 있다.
한편, AVN 가상화 머신(440)은, 오디오 데이터, 라디오 데이터, USB 데이터, 무선 통신 데이터의 입출력을 위한 인터페이스(441), 레가시(legacy) 가상화 머신(410)의 인터페이스(412)와의 통신을 위한 인터페이스(442), 레가시(legacy) 가상화 머신(410)의 인터페이스(413)와의 통신을 위한 인터페이스(443)를 구비할 수 있다.
이러한 시스템(400)에 의하면, CAN 통신 데이터는, 클러스터 가상화 머신(430)에서만 입출력되므로, AVN 가상화 머신(440)에서는 CAN 통신 데이터를 활용하지 못하는 단점이 있다.
또한, 도 4의 시스템(400)에 의하면, 오디오 데이터, 라디오 데이터, USB 데이터, 무선 통신 데이터는, AVN 가상화 머신(440)에서만 입출력되므로, 클러스터 가상화 머신(430)에서는 이러한 데이터를 활용하지 못하는 단점이 있다.
한편, 레가시(legacy) 가상화 머신(410)에서 입출력되는 메모리 데이터, 이더넷 통신 데이터를 위해, 클러스터 가상화 머신(430)과 클러스터 가상화 머신(430)가 각각 별도의 인터페이스(431,432,441,442)를 구비해야 하는 단점이 있다.
이에 본 발명에서는, 도 4의 시스템을 개선하기 위한 방안을 제시한다. 즉, 도 4와 달리, 가상화 머신을 서버 가상화 머신과 게스트 가상화 머신으로 구분하고, 각종 메모리 데이터, 통신 데이터 등을 게스트 가상화 머신에서 입출력되지 않고, 서버 가상화 머신에서 입출력되도록 한다. 이에 대해서는 도 5 이하를 참조하여 기술한다.
도 5는 본 발명의 실시예에 따른 신호 처리 장치에서 구동되는 시스템의 일예를 도시한 도면이다.
도면을 참조하면, 도 5의 시스템(500)은, 신호 처리 장치(170) 내의 프로세서(175) 내의 하이퍼바이저(505) 상에서, 서버 가상화 머신인 제1 가상화 머신(520), 게스트 가상화 머신인 제2 가상화 머신(530), 게스트 가상화 머신은 제3 가상화 머신(540)이 실행되는 것을 예시한다.
제2 가상화 머신(530)은, 클러스터 디스플레이(180a)를 위한 가상화 머신이고, 제3 가상화 머신(540)은 AVN 디스플레이(180b)를 위한 가상화 머신일 수 있다.
즉, 제2 가상화 머신(530)과, 제3 가상화 머신(540)은, 각각 클러스터 디스플레이(180a)과 AVN 디스플레이(180b)의 영상 렌더링을 위해 동작할 수 있다.
한편, 도 5의 신호 처리 장치(170)에서 구동되는 시스템(500)은, 프로세서(175) 내의 하이퍼바이저(505) 상에서, 레가시(legacy) 가상화 머신(510)도 실행되는 것을 예시한다.
레가시(legacy) 가상화 머신(510)은, 메모리(140)와의 데이터 통신, 및 이더넷 통신을 위한 인터페이스(511)을 구비한다.
도면에서는, 인터페이스(511)가, 피지컬 디바이스 드라이버(physical device driver)인 것을 예시하나, 다양한 변형이 가능하다.
한편, 레가시(legacy) 가상화 머신(510)은, 제2 내지 제3 가상화 머신(530,540)과의 데이터 통신을 위한 인터페이스(virtio-backend interface)(512)를 더 구비할 수 있다.
제1 가상화 머신(520)은, 오디오 데이터, 라디오 데이터, USB 데이터, 무선 통신 데이터의 입출력을 위한 인터페이스(521), 게스트 가상화 머신과의 데이터 통신을 위한 입출력 서버 인터페이스(522)를 구비할 수 있다.
즉, 서버 가상화 머신인 제1 가상화 머신(520)은, 표준가상화기술(VirtIO)에 의해 가상화되기 힘든 I/O 들을 다수의 게스트 가상화 머신, 예를 들어, 제2 내지 제3 가상화 머신(530,540) 등에 제공할 수 있다.
한편, 서버 가상화 머신인 제1 가상화 머신(520)은, 라디오 데이터, 오디오 데이터 등을 슈퍼바이저(Supervisor) 수준에서 제어하고, 다수의 게스트 가상화 머신, 예를 들어, 제2 내지 제3 가상화 머신(530,540) 등에 제공할 수 있다.
한편, 한편, 제1 가상화 머신(520)은, 시스템 및 디스플레이 관리를 위한 슈퍼바이저리 서비스(supervisory service)와, 외부 장치 연결 제어와 차량(100) 정보 관리를 위한 시스템 서비스를 수행할 수 있다. 이에 따라, 내부 시스템 관리 등을 효율적으로 수행할 수 있게 된다.
한편, 서버 가상화 머신인 제1 가상화 머신(520)은, 차량 데이터, 센서 데이터, 차량 주변 정보 등을 처리하고, 처리된 데이터 또는 정보 등을 다수의 게스트 가상화 머신, 예를 들어, 제2 내지 제3 가상화 머신(530,540) 등에 제공할 수 있다.
한편, 제1 가상화 머신(520)은, 차량 데이터(vehicle data)의 처리, 오디오 라우팅(Audio routing) 관리 등과 같은, 서비스(Supervisory Services)를 제공할 수 있다.
다음, 제2 가상화 머신(530)은, 제1 가상화 머신(520)과의 데이터 통신을 위한 입출력 클라이언트 인터페이스(532)와, 입출력 클라이언트 인터페이스(532)를 제어하는 APIs(533)를 구비할 수 있다.
또한, 제2 가상화 머신(530)은, 레가시 가상화 머신(510)과의 데이터 통신을 위한 인터페이스(virtio-backend interface)를 구비할 수 있다.
제2 가상화 머신(530)은, 인터페이스(virtio-backend interface)를 통해, 레가시(legacy) 가상화 머신(510)의 인터페이스(virtio-backend interface)(512)로부터 메모리(140)와의 통신에 의한 메모리 데이터 또는 이더넷 통신에 의한 이더넷 데이터 등을 수신할 수 있다.
다음, 제3 가상화 머신(540)은, 제1 가상화 머신(520)과의 데이터 통신을 위한 입출력 클라이언트 인터페이스(542)와 입출력 클라이언트 인터페이스(542)를 제어하는 APIs(543)를 구비할 수 있다.
또한, 제3 가상화 머신(540)은, 레가시 가상화 머신(510)과의 데이터 통신을 위한 인터페이스(virtio-backend interface)를 구비할 수 있다.
제3 가상화 머신(540)은, 인터페이스(virtio-backend interface)를 통해, 레가시(legacy) 가상화 머신(510)의 인터페이스(virtio-backend interface)(512)로부터 메모리(140)와의 통신에 의한 메모리 데이터 또는 이더넷 통신에 의한 이더넷 데이터 등을 수신할 수 있다.
한편, 레가시(legacy) 가상화 머신(510)은, 도 5와 달리, 제1 가상화 머신(520) 내에 구비되는 것도 가능하다.
이러한 시스템(500)에 의하면, CAN 통신 데이터는, 제1 가상화 머신(520)에서만 입출력되나, 제1 가상화 머신(520)에서의 데이터 처리를 통해, 다수의 게스트 가상화 머신, 예를 들어, 제2 내지 제3 가상화 머신(530,540) 등에 제공될 수 있다. 따라서, 제1 가상화 머신(520)의 처리에 의한 1:N 데이터 통신이 가능하게 된다.
또한, 도 5의 시스템(500)에 의하면, 오디오 데이터, 라디오 데이터, USB 데이터, 무선 통신 데이터는, 제1 가상화 머신(520)에서만 입출력되나, 제1 가상화 머신(520)에서의 데이터 처리를 통해, 다수의 게스트 가상화 머신, 예를 들어, 제2 내지 제3 가상화 머신(530,540) 등에 제공될 수 있다. 따라서, 제1 가상화 머신(520)의 처리에 의한 1:N 데이터 통신이 가능하게 된다.
또한, 도 5의 시스템(500)에 의하면, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)에 대한 터치 입력(Touch)은, 제1 가상화 머신(520)에만 입력되고, 제2 내지 제3 가상화 머신(530,540)에는 입력되지 않는다. 터치 입력(Touch)에 대한 정보를 제2 가상화 머신(530) 또는 제3 가상화 머신(540)으로 전송한다.
이에 따라, 터치 입력(Touch)에 대한 처리를 신속하고 정확하게 수행할 수 있게 된다. 또한, 구동되는 가상화 머신의 개수가 증가되더라도, 터치 입력(Touch)에 대한 처리를 신속하고 정확하게 수행할 수 있게 된다.
한편, 도 5의 시스템(500)에서 제2 내지 제3 가상화 머신(530,540)은 서로 다른 OS 기반으로 동작할 수 있다.
예를 들어, 제2 가상화 머신(540)은 리눅스 OS 기반 하에 동작하며, 제3 가상화 머신(540)은 웹 OS 기반 하에 동작할 수 있다.
제1 가상화 머신(520)은, 제2 내지 제3 가상화 머신(530,540)은 서로 다른 OS 기반 하에 동작하더라도, 데이터 공유를 위해, 하이퍼바이저(505) 기반의 공유 메모리(508)가 설정할 수 있다. 이에 따라, 제2 내지 제3 가상화 머신(530,540)이, 서로 다른 운영 체제(Operating system;OS) 하에 동작하더라도, 동일한 데이터 또는 동일한 영상을 동기화하여 공유할 수 있게 된다. 결국, 복수의 디스플레이(180a,180b)에 동일한 데이터 또는 동일한 영상을 동기화하여 표시할 수 있게된다.
한편, 제1 가상화 머신(520)은, 제2 내지 제3 가상화 머신(530,540)은 서로 다른 OS 기반 하에 동작하더라도, 터치 입력(Touch)에 대한 정보를 제2 가상화 머신(530) 또는 제3 가상화 머신(540)으로 전송한다. 이에 따라, 제2 내지 제3 가상화 머신(530,540)이, 서로 다른 운영 체제(Operating system;OS) 하에 동작하더라도, 터치 입력(Touch)에 대한 처리를 신속하고 정확하게 수행할 수 있게 된다.
한편, 제1 가상화 머신(520)은, 제2 내지 제3 가상화 머신(530,540)을 통해, 제1 디스플레이(180a)와 제2 디스플레이(180b)에 표시되는 오버레이의 제어를 위한 디스플레이 매니저(527)와, 디스플레이 레이어 서버(529)를 구비할 수 있다.
디스플레이 레이어 서버(529)는, 제2 가상화 머신(530)이 제공하는 제1 오버레이와, 제3 가상화 머신(540)이 제공하는 제2 오버레이를 수신할 수 있다.
한편, 디스플레이 레이어 서버(529)는, 제1 오버레이 또는 제2 오버레이와 별도의 버츄얼 오버레이(virtual overlay)를, 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나에 전송할 수 있다.
한편, 제1 가상화 머신(520) 내의 디스플레이 매니저(527)는, 제2 가상화 머신(530)이 제공하는 제1 오버레이와, 제3 가상화 머신(540)이 제공하는 제2 오버레이를, 디스플레이 레이어 서버(529)를 통해 수신할 수 있다.
그리고, 제1 가상화 머신(520) 내의 디스플레이 매니저(527)는, 제1 오버레이 또는 제2 오버레이와 별도의 버츄얼 오버레이(virtual overlay)를, 디스플레이 레이어 서버(529)를 통해, 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나에 전송하도록 제어할 수 있다.
이에 대응하여, 제2 가상화 머신(530)은, 제1 오버레이와 버츄얼 오버레이(virtual overlay)를 합성하여, 제1 디스플레이(180a)에 표시되도록 제어할 수 있다.
또한, 제3 가상화 머신(540)은, 제2 오버레이와 버츄얼 오버레이(virtual overlay)를 합성하여, 제2 디스플레이(180b)에 표시되도록 제어할 수 있다.
한편, 제1 가상화 머신(520)은, 외부로부터의 입력 신호를 수신하는 입력 매니저(524)를 구비할 수 있다. 이때의 입력 신호는, 차량 내의 소정 버튼(시동 버튼 등)의 입력 신호, 터치 입력 신호, 또는 음성 입력 신호 등일 수 있다.
예를 들어, 제1 가상화 머신(520) 내의 입력 매니저(524)는, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)로부터의 터치 입력을 수신할 수 있다.
한편, 제1 가상화 머신(520)은, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)로부터의 터치 입력과 관련한 터치 입력(Touch)에 대한 정보를 제2 가상화 머신(530) 또는 제3 가상화 머신(540)으로 전송하는 터치 서버(528)를 구비할 수 있다.
예를 들어, 제1 가상화 머신(520) 내의 터치 서버(528)는, 제1 디스플레이(180a)에 대응하는 터치 입력이 있는 경우, 터치 입력(Touch)에 대한 정보를, 제2 가상화 머신(530)으로 전송할 수 있다.
한편, 제1 가상화 머신(520) 내의 터치 서버(528)는, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)로부터의 터치 입력을 수신할 수도 있다.
한편, 제1 가상화 머신(520)은, 차량(100) 내 센서 장치(760)로부터의 센서 데이터와, 차량(100) 내 튜너(105)로부터 라디오 신호를 수신하는 제1 호출 인터페이스(521)와, 제1 호출 인터페이스(521)에서 수신된 센서 데이터 또는 라디오 신호에 대응하는 데이터를 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나로 전송하는 입출력 서버 인터페이스(522)를 구비한다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다.
한편, 제2 가상화 머신(530) 및 제3 가상화 머신(540)은, 제1 가상화 머신(520) 내의 제1 호출 인터페이스(521)로부터의 센서 데이터 또는 라디오 신호에 대응하는 데이터를 수신하기 위한 입출력 클라이언트 인터페이스(532, 542)를 각각 구비할 수 있다. 이에 따라, 센서 데이터를 신속하게 공유할 수 있게 된다.
한편, 제2 가상화 머신(530) 및 제3 가상화 머신(540)은, 차량(100) 내 센서 장치(760) 및 차량(100) 내 튜너(105)와 데이터 통신을 수행하지 않는다. 이에 따라, 복수의 가상화 머신 사이에서 리소스를 효율적으로 사용할 수 있게 된다.
한편, 제1 가상화 머신(520)은, 센서 데이터 또는 라디오 신호에 대응하는 데이터를 공유 메모리(508)에 저장되도록 제어하며, 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나는, 공유 메모리(508)에 저장된 센서 데이터 또는 라디오 신호에 대응하는 데이터를 수신할 수 있다. 이에 따라, 센서 데이터 또는 라디오 신호에 대응하는 데이터를 신속하게 수신하고 처리할 수 있게 된다.
한편, 제1 가상화 머신(520)은, 제2 가상화 머신(530) 또는 제3 가상화 머신(540)으로, 센서 데이터 또는 라디오 신호에 대응하는 데이터가 저장되는 공유 메모리(508)에 대한 버퍼 인덱스를 전송하고, 제2 가상화 머신(530) 또는 제3 가상화 머신(540)은, 수신한 버퍼 인덱스에 기초하여, 공유 메모리(508)에 저장된 센서 데이터 또는 라디오 신호에 대응하는 데이터를 독출할 수 있다. 이에 따라, 센서 데이터 또는 라디오 신호에 대응하는 데이터를 신속하게 공유할 수 있게 된다.
한편, 제1 가상화 머신(520)은, 제1 호출 인터페이스(521)를 통해, 차량(100)의 휠 속도 센서 데이터를 수신하고, 처리하여, 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나로, 처리된 휠 속도 센서 데이터 또는 처리된 휠 속도 센서 데이터에 대응하는 속도 정보를, 입출력 서버 인터페이스(522)를 통해, 전송할 수 있다. 이에 따라, 차량(100)의 휠 속도 센서 데이터를 신속하게 공유할 수 있게 된다.
한편, 제1 가상화 머신(520)은, 제1 호출 인터페이스(521)를 통해, 차량(100)의 공조 데이터를 수신하고, 처리하여, 제2 가상화 머신(530) 또는 제3 가상화 머신(540) 중 적어도 하나로, 처리된 공조 데이터 또는 처리된 공조 데이터에 대응하는 차량(100) 내부 온도 정보를, 입출력 서버 인터페이스(522)를 통해, 전송할 수 있다. 이에 따라, 차량(100)의 공조 데이터를 신속하게 공유할 수 있게 된다.
한편, 차량(100) 내 센서 장치(760)로부터의 센서 데이터는, CAN 통신에 기초하여 수신되며, 프로세서(175) 내의 제1 가상화 머신(520) 내의 제1 호출 인터페이스(521)는, USB 데이터, 블루투스 통신 데이터를 더 수신할 수 있다. 이에 따라, CAN 통신 기반의 데이터를 신속하게 공유할 수 있게 된다.
도 6은 본 발명의 실시예에 따른 신호 처리 장치에서 구동되는 시스템의 다른 예를 도시한 도면이다.
도면을 참조하면, 도 6의 신호 처리 장치(170) 내의 프로세서(175)에서 구동되는 시스템(500b)에 의하면, 신호 처리 장치(170) 내의 프로세서(175)는, 프로세서(175) 내의 하이퍼바이저(505) 상에서, 제1 가상화 머신 내지 제3 가상화 머신(520~540)을 실행하며, 프로세서(175) 내의 제1 가상화 머신(520)은, 제2 가상화 머신(530) 및 제3 가상화 머신(540)으로, 데이터 전송을 위해, 하이퍼바이저(505) 기반의 공유 메모리(508)가 설정되도록 제어한다.
예를 들어, 데이터로, 터치 입력(Touch)에 대한 정보가 예시될 수 있다. 이에 따라, 터치 입력(Touch)에 대한 정보를 제2 가상화 머신(530) 또는 제3 가상화 머신(540)으로 전송되며, 결국, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)에 대한 터치 입력(Touch)에 대한 처리를 신속하고 정확하게 수행할 수 있게 된다. 또한, 구동되는 가상화 머신의 개수가 증가되더라도, 터치 입력(Touch)에 대한 처리를 신속하고 정확하게 수행할 수 있게 된다.
다른 예로, 데이터로, 영상 데이터가 예시될 수 있다. 이에 따라, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)에 영상을 표시할 수 있게 된다.
한편, 공유 메모리(508)에 동일한 영상 데이터가 공유되는 경우, 차량 내의 복수의 디스플레이(180a~180b)에서 동일한 영상을 동기화하여 표시할 수도 있게 된다.
또 다른 예로, 데이터로, CAN 통신 데이터, 오디오 데이터, 라디오 데이터, USB 데이터, 무선 통신 데이터, 위치 정보 데이터 등이 예시될 수 있다. 이에 따라, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)에, 해당하는 데이터에 대한 정보를 표시할 수 있게 된다.
한편, 도 6에는 표시되지 않았지만, 레가시 가상화 머신(510)은, 메모리(140)로부터의 메모리 데이터, 또는 이더넷 통신에 의해 이더넷 데이터를, 하이퍼바이저(505) 기반의 공유 메모리(508)를 이용하여, 제2 가상화 머신(530) 및 제3 가상화 머신(540)으로, 전송할 수 있다. 이에 따라, 메모리 데이터 또는 이더넷 데이터에 대응하는 정보가, 제1 디스플레이(180a) 또는 제2 디스플레이(180b)에 표시될 수 있게 된다.
한편, 도 6의 시스템(500b) 내의 제1 가상화 머신(520)은, 도 5의 시스템(500) 내의 제1 가상화 머신과 유사하게, 디스플레이 매니저(527)와, 디스플레이 레이어 서버(529), 입력 매니저(524), 터치 서버(528)를 구비할 수 있다.
한편, 도 6의 시스템(500b) 내의 제1 가상화 머신(520) 내의 입출력 서버 인터페이스(522)는, 도 5와 달리, 디스플레이 레이어 서버(529)와, 터치 서버(528)를 구비할 수 있다.
디스플레이 매니저(527)와, 디스플레이 레이어 서버(529), 입력 매니저(524), 터치 서버(528)의 동작은, 도 5와 동일하므로 그 설명을 생략한다.
한편, 도 6의 제1 가상화 머신(520)은, 전체 시스템 제어를 위한 시스템 매니저(system manager), 차량 정보 관리를 위한 차량 정보 매니저(vehicle information manager), 오디오 제어를 위한 오디오 매니저(audio manager), 라디오 제어를 위한 라디오 매니저(radio manager) 등을 더 구비할 수 있다.
한편, 도 6의 시스템(500b) 내의 제1 가상화 머신(520) 내의 입출력 서버 인터페이스(522)는, GPS 정보의 입출력을 위한 GNSS 서버, 블루투스 입출력을 위한 블루투스 서버, 와이파이 입출력을 위한 와이파이 서버, 카메라 데이터 입출력을 위한 카메라 서버 등을 더 포함할 수 있다.
도 7은 본 발명의 실시예에 따른 신호 처리 장치에서 구동되는 시스템의 또 다른 예를 도시한 도면이다.
도면을 참조하면, 도 7의 신호 처리 장치(170) 내의 프로세서(175)에서 구동되는 시스템(500c)은, 도 6의 시스템(500b)과 거의 유사하다.
즉, 도 6과 같이, 도 7의 프로세서(175)는, 프로세서(175) 내의 하이퍼바이저(505) 상에서, 제1 가상화 머신 내지 제3 가상화 머신(520~540)을 실행한다.
다만, 도 7에서는 도 6과 달리, 디스플레이 레이어 서버(529)와, 터치 서버(528)가, 입출력 서버 인터페이스(522)의 외부에, 제1 가상화 머신(520) 내에서 구비되어 실행될 수 있다.
또한, 도 6과 달리, GPS 정보의 입출력을 위한 GNSS 서버, 블루투스 입출력을 위한 블루투스 서버, 와이파이 입출력을 위한 와이파이 서버, 카메라 데이터 입출력을 위한 카메라 서버 등이, 입출력 서버 인터페이스(522)의 외부에, 제1 가상화 머신(520) 내에서 구비되어 실행될 수 있다.
즉, 제1 가상화 머신(520) 내에, 디스플레이 매니저(527)와, 디스플레이 레이어 서버(529), 입력 매니저(524), 터치 서버(528)가 구비되어 실행될 수 있다.
한편, 도 6의 시스템(500b) 내의 제1 가상화 머신(520) 내의 입출력 서버 인터페이스(522)는, 도 5와 달리, 디스플레이 레이어 서버(529)와, 터치 서버(528)를 구비할 수 있다.
디스플레이 매니저(527)와, 디스플레이 레이어 서버(529), 입력 매니저(524), 터치 서버(528)의 동작은, 도 5와 동일하므로 그 설명을 생략한다.
도 8 내지 도 9b는 도 5의 설명에 참조되는 도면이다.
먼저, 도 8은, 본 발명의 실시예에 따른 시스템(500) 내의 프로세서(175) 내의 하이퍼바이저(505) 상에서, 제1 가상화 머신 내지 제3 가상화 머신(520~540)을 실행하며, 프로세서(175) 내의 제1 가상화 머신(520)이, 제2 가상화 머신(530) 및 제3 가상화 머신(540)으로, 동일한 데이터 전송을 위해, 하이퍼바이저(505) 기반의 공유 메모리(508)가 설정되도록 제어하는 것을 예시한다.
이에 따라, 차량 내의 복수의 디스플레이(180a~180b)에서 동일한 영상을 동기화하여 표시할 수 있게 된다.
한편, 복수의 가상화 머신 사이의 고속의 데이터 통신을 수행할 수 있게 된다. 나아가, 복수의 가상화 머신이 서로 다른 운영체제에 의해 구동되더라도 고속의 데이터 통신을 수행할 수 있게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 제1 가상화 머신(520)에서 처리된 데이터를, 다른 가상화 머신으로 전송하는 경우, 가상화 머신의 개수에 대응하는 개수의 메모리 할당이 아닌, 하나의 공유 메모리(508)를 이용할 수 있다. 이에 따라, 가상화 머신들 사이에서의 1:1 방식의 데이터 통신이 아니라, 공유 메모리(508)를 이용하여, 1:N 방식의 데이터 통신이 가능하게 된다.
한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 입출력 서버 인터페이스(522)와 보안 매니저(526)를 포함할 수 있다.
한편, 제2 가상화 머신(530) 및 제3 가상화 머신(540)은, 각각 입출력 클라이언트 인터페이스(532, 542)를 포함할 수 있다. 이에 따라, 입출력 서버 인터페이스(522)와, 입출력 클라이언트 인터페이스(532, 542)를 이용하여, 복수의 가상화 머신 사이의 고속의 데이터 통신을 수행할 수 있게 된다.
제1 가상화 머신(520) 내의 입출력 서버 인터페이스(522)는, 제2 가상화 머신(530) 및 제3 가상화 머신(540) 내의 각 입출력 클라이언트 인터페이스(532, 542)로부터 동일 데이터 전송 요청을 수신하고, 이에 기초하여, 공유 데이터를 보안 매니저(526)를 통해, 공유 메모리(508)로 전송할 수 있다.
도 9a는 공유 데이터 전송에 대한 보다 상세한 도면을 예시한다.
도면을 참조하면, 공유 데이터 전송을 위해, 제1 가상화 머신(520) 내의 입출력 서버 인터페이스(522)는, 보안 매니저(526)로 공유 메모리(508)의 할당 요청을 전송한다(S1).
다음, 보안 매니저(526)는, 하이퍼바이저(505)를 이용하여 공유 메모리(508)를 할당하고(S2), 공유 메모리(508)에 공유 데이터를 기록할 수 있다.
한편, 입출력 클라이언트 인터페이스(532, 542)는, 공유 메모리(508) 할당 이후, 입출력 서버 인터페이스(522)로 연결 요청을 전송할 수 있다(S3).
한편, 입출력 서버 인터페이스(522)는, 공유 메모리(508) 할당 이후, 입출력 클라이언트 인터페이스(532, 542)로, 키 데이터를 포함하는 공유 메모리(508)에 대한 정보를 전송한다(S4). 이때의 키 데이터는, private key 데이터일 수 있다.
즉, 한편, 프로세서(175) 내의 제1 가상화 머신(520)은, 공유 메모리(508)의 설정 이후, 공유 메모리(508)에 대한 정보를, 제2 가상화 머신(530) 및 제3 가상화 머신(540)으로 전송할 수 있다.
다음, 제1 가상화 머신(520) 내의 입출력 서버 인터페이스(522)는, 가상화 머신 사이의 분산 처리 제어를 위해, 데이터와 별도의, 커맨드 또는 이벤트 처리를 위한 커맨드 큐(command queue)를 생성하도록 제어한다(S5).
도면에서는, 입출력 서버 인터페이스(522)의 제어에 의해, 하이퍼바이저(505) 내의 커맨드 큐 버퍼(504)에서, 커맨드 큐가 생성되는 것을 예시한다. 그러나, 이에 한정되지 않으며, 입출력 서버 인터페이스(522)의 제어에 의해, 하이퍼바이저(505) 내가 아닌, 제1 가상화 머신(520) 내에서 생성되는 것도 가능하다.
다음, 각 입출력 클라이언트 인터페이스(532, 542)는, 커맨드 큐 버퍼(504)에 억세스 하여, 생성된 커맨드 큐 또는 커맨드 큐에 대한 정보를 수신한다(S6).
예를 들어, 각 입출력 클라이언트 인터페이스(532, 542)로의 커맨드가 동일한 경우, 생성된 커맨드 큐는 동일할 수 있다.
다른 예로, 각 입출력 클라이언트 인터페이스(532, 542)로의 커맨드가 서로 다른 경우, 서로 다른 커맨드 큐가, 각 입출력 클라이언트 인터페이스(532, 542)로 전달될 수 있다.
다음, 각 입출력 클라이언트 인터페이스(532, 542)는, 입출력 클라이언트 인터페이스(532, 542)는, 수신한 키 데이터에 기초하여 공유 메모리(508)에 접근하고(S5), 공유 데이터를 공유 메모리(508)로부터 카피(copy) 또는 독출할 수 있다(S7).
특히, 각 입출력 클라이언트 인터페이스(532, 542)가 동일한 공유 데이터를 전달받는 경우, 입출력 클라이언트 인터페이스(532, 542)는, 동일한 커맨드 큐 및 동일한 키 데이터에 기초하여 공유 메모리(508)에 접근하고(S5), 공유 데이터를 공유 메모리(508)로부터 카피(copy) 또는 독출할 수 있다.
이에 따라, 제2 가상화 머신(530) 및 제3 가상화 머신(540)에서 공유 메모리(508)에 억세스 가능하게 되며, 결국, 공유 데이터를 공유할 수 있게 된다.
예를 들어, 공유 데이터가, 영상 데이터인 경우, 제2 가상화 머신(530) 및 제3 가상화 머신(540)에서 영상 데이터를 공유하게 되며, 결국 차량 내의 복수의 디스플레이(180a~180b)에서 동일한 공유 영상을 동기화하여 표시할 수 있게 된다.
도 9b는, 도 9a의 시스템(500)에 의해, 제2 가상화 머신(530)이 공유 메모리(508)를 통해 수신된 영상 데이터를 제1 디스플레이(180a)에 표시하고, 제3 가상화 머신(540)이 공유 메모리(508)를 통해 수신된 영상 데이터를 제2 디스플레이(180b)에 표시하는 것을 예시한다.
도 9b에서는, 제1 디스플레이(180a)에 표시되는 영상(905a)과 제2 디스플레이(180b)에 표시되는 영상(905b)의 동기화 수행되어, T1 시점에, 동일한 영상(905a,905b)이 각각 표시되는 것을 예시한다.
즉, 프로세서(175) 내의 제1 가상화 머신(520)에서 처리된 영상 데이터는, 공유 메모리(508)를 통해, 제2 가상화 머신(530) 및 제3 가상화 머신(540)으로 전송되며, 영상 데이터에 기초하여, 제1 디스플레이(180a)에 표시되는 제1 영상(905a)과, 제2 디스플레이(180b)에 표시되는 제2 영상(905b)은 서로 동일할 수 있다. 이에 따라, 차량 내의 복수의 디스플레이(180a~180b)에서 동일한 영상을 동기화하여 표시할 수 있게 된다.
도 10a 내지 도 10b는 본 발명과 관련한 신호 처리 장치를 설명하는 도면이다.
도 10a는 본 발명과 관련한 신호 처리 장치의 일예를 도시한다.
도면을 참조하면, 본 발명과 관련한 신호 처리 장치(170x)는, 복수의 가상화 머신(MAax,MAbx)을 실행할 수 있다.
복수의 가상화 머신(MAax,MAbx)은, 서비스 이용을 위해, 네트워크 통신에 기반한 원격 절차 호출(Remote Procedure Call; RPC)을 이용할 수 있다.
이를 위해, 복수의 가상화 머신(MAax,MAbx) 중 제1 가상화 머신(MAbx)은, 원격 절차 호출을 위한 서비스를 제공하는 피호출자(RCE)를 실행하고, 복수의 가상화 머신(MAax,MAbx) 중 제2 가상화 머신(MAax)은, 원격 절차 호출의 서비스 이용을 위한 호출자(RCA)를 실행한다.
한편, 복수의 가상화 머신(MAax,MAbx)은, 각각, 네트워크 데이터를 전기 신호로 변환하는 네트워크 스택(NSTaa,NSTab)를 구비할 수 있다.
한편, 제2 가상화 머신(MAax)은, 호출자(RCA)로부터의 요청을 수신하여 직렬화하여 네트워크 스택(NSTaa)으로 제공하는 패킹부(Pkaa)와, 네트워크 스택(NSTaa)으로부터의 응답을 수신하여 역직렬화하여 호출자(RCA)로 제공하는 언패킹부(UPkaa)와, 네트워크를 사용하는 프로세서(PNaa)를 구비할 수 있다.
한편, 제1 가상화 머신(MAbx)은, 네트워크 스택(NSTab)으로부터의 요청을 수신하여 역직렬화하여 피호출자(RCE)로 제공하는 언패킹부(UPkab)와, 피호출자(RCE)로부터의 응답을 수신하여 직렬화하여 네트워크 스택(NSTab)으로 제공하는 패킹부(Pkab)와, 네트워크를 사용하는 프로세서(PNab)를 구비할 수 있다.
도면의 신호 처리 장치(170x)에 의하면, 네트워크 통신에 기반한 원격 절차 호출을 이용하므로, 네트워크가 가능한 경우, 사용이 가능하게 된다.
다만, 신호 처리 장치(170x)에 의하면, 부팅 등에 의해, 네트워크 활성화 전에, 원격 절차 호출이 이용이 불가능하다는 단점이 있으며, 네트워크 계층에서 오는 오버헤드(overhead)가 문제될 수 있다.
도 10b는 본 발명과 관련한 신호 처리 장치의 다른 예를 설명하는 도면이다.
도면을 참조하면, 본 발명과 관련한 신호 처리 장치(170y)는, 복수의 가상화 머신(MAay,MAby)과, 공유 메모리(SHy)를 구비하는 하이퍼바이저(HPV)를 실행할 수 있다.
복수의 가상화 머신(MAay,MAby)은, 서비스 이용을 위해, 네트워크 통신에 기반한 원격 절차 호출(Remote Procedure Call; RPC)을 이용할 수 있다.
이를 위해, 복수의 가상화 머신(MAay,MAby) 중 제1 가상화 머신(MAby)은, 원격 절차 호출을 위한 피호출자(RCE)를 실행하고, 복수의 가상화 머신(MAay,MAby) 중 제2 가상화 머신(MAay)은, 원격 절차 호출을 위한 호출자(RCA)를 실행한다.
한편, 복수의 가상화 머신(MAay,MAby)은, 각각, 네트워크 데이터를 전기 신호로 변환하는 네트워크 스택(NSTaa,NSTab)를 구비할 수 있다.
한편, 제2 가상화 머신(MAay)은, 호출자(RCA)로부터의 요청을 수신하여 직렬화하여 네트워크 스택(NSTaa)으로 제공하는 패킹부(Pkaa)와, 네트워크 스택(NSTaa)으로부터의 응답을 수신하여 역직렬화하여 호출자(RCA)로 제공하는 언패킹부(UPkaa)와, 네트워크를 사용하는 프로세서(PNaa)와, 공유 메모리(SHy)의 구동을 위한 공유 메모리 드라이버(SHMba)를 구비할 수 있다.
한편, 제1 가상화 머신(MAby)은, 네트워크 스택(NSTab)으로부터의 요청을 수신하여 역직렬화하여 피호출자(RCE)로 제공하는 언패킹부(UPkab)와, 피호출자(RCE)로부터의 응답을 수신하여 직렬화하여 네트워크 스택(NSTab)으로 제공하는 패킹부(Pkab)와, 네트워크를 사용하는 프로세서(PNab)와, 공유 메모리(SHy)의 구동을 위한 공유 메모리 드라이버(SHMbb)를 구비할 수 있다.
도 10a의 신호 처리 장치(170x)와 비교하여, 공유 메모리(SHy)를 구비하는 하이퍼바이저(HPV)가 사용되므로, 전기 신호로 변환하여 물리 채널로 네트워크 데이터를 전송하는 대신에, 공유 메모리(SHy)를 이용하여 네트워크 데이터를 전송할 수 있게 된다.
그러나, 신호 처리 장치(170y)에 의하면, 네트워크 통신에 기반한 원격 절차 호출을 이용하므로, 네트워크가 가능한 경우, 사용이 가능하게 된다. 그러나, 도 10a의 신호 처리 장치(170x)와 동일하게, 신호 처리 장치(170y)는, 부팅 등에 의해, 네트워크 활성화 전에, 원격 절차 호출이 이용이 불가능하다는 단점이 있으며, 네트워크 계층에서 오는 오버헤드(overhead)가 문제될 수 있다.
또한, 신호 처리 장치(170y)에 의하면, 원격 절차 호출을 위해, 공유 메모리(SHy)를 이용하는 것은 물론, 네트워크를 이용한 다른 모든 프로세스 들의 데이터가, 공유 메모리(SHy) 내에 혼재하여, 리소스의 효율적으로 사용하지 못하고 신속한 상호 작용이 수행되지 못한다는 단점이 있다.
이러한 점을 해결하기 위해, 본 발명의 실시예에서는, 공유 메모리 내에 원격 절차 호출을 위한 상호 공유 영역(IVS)을 설정하고, 이를 이용하는 방안을 제안한다. 즉, 경량의 원격 절차 호출(RPC)을 이용하는 방안을 제안한다. 이에 대해서는, 도 11 이하를 참조하여 기술한다.
도 11은 본 발명의 실시예에 따른 신호 처리 장치의 내부 동작을 설명하는 도면이다.
도면을 참조하면, 본 발명의 일 실시예에 따른 신호 처리 장치(170m)는, 차량에 장착되는 디스플레이를 위한 신호 처리를 수행하는 프로세서(175)를 포함하며, 프로세서(175)는, 하이퍼바이저(HHV)를 실행하며, 하이퍼바이저(HHV) 상에서, 복수의 가상화 머신(VMA,VMB)을 실행한다.
복수의 가상화 머신(VMA,VMB) 중 제1 가상화 머신(VMB)과, 제2 가상화 머신(VMA)은, 하이퍼바이저(HHV) 내의 공유 메모리(SMR) 내에 원격 절차 호출(Remote Procedure Call; RPC)을 위한 상호 공유 영역(IVS)을 공유한다.
한편, 상호 공유 영역(IVS)은, 도면에서와 같이, Inter-VM Stack Frame 으로 명명될 수도 있다.
한편, 제1 가상화 머신(VMB)은, 제2 가상화 머신(VMA)의 호출자(RCA)에 대응하여 데이터를 수신하는 피호출자(RCE)와, 상호 공유 영역(IVS)으로의 억세스를 위한 제1 호출 인터페이스(eRCb)를 실행한다.
즉, 제1 가상화 머신(VMB)은, 원격 절차 호출의 서비스 제공을 위한 피호출자(RCE)와, 상호 공유 영역(IVS)으로의 억세스를 위한 제1 호출 인터페이스(eRCb)를 실행한다.
한편, 제2 가상화 머신(VMA)은, 원격 절차 호출을 위한 호출자(RCA)와, 상호 공유 영역(IVS)으로의 억세스를 위한 제2 호출 인터페이스(eRCa)를 실행한다.
즉, 제2 가상화 머신(VMA)은, 원격 절차 호출의 서비스 이용을 위한 호출자(RCA)와, 상호 공유 영역(IVS)으로의 억세스를 위한 제2 호출 인터페이스(eRCa)를 실행한다.
이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다. 또한, 데이터 공유와 원격 절차 호출을 통합할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb)와 제2 호출 인터페이스(eRCa)에서의 호출 인터페이스는, Embedded Virtualization system RPC 으로 명명될 수도 있다.
한편, 도 10a 또는 도 10b와 달리, 본 발명의 일 실시예에 따른 신호 처리 장치(170m)는, 각 가상화 머신(VMA,VMB) 내에, 각각의 호출 인터페이스(eRCa, eRCb)를 실행한다.
한편, 제1 가상화 머신(VMB)은, 공유 메모리(SMR) 구동을 위한 제1 공유 메모리 드라이버(SMDb)를 더 실행할 수 있다.
한편, 제2 가상화 머신(VMA)은, 공유 메모리(SMR) 구동을 위한 제2 공유 메모리 드라이버(SMDa)를 더 실행할 수 있다.
한편, 하이퍼바이저(HHV) 내에, 호스트 드라이버(HD)와, 공유 메모리(SMR)가 실행될 수 있다.
공유 메모리(SMR) 내에, 컨트롤 페이지 테이블(CPT), RPC 컨트롤 페이지, 상호 공유 영역(IVS)과, 호출 저장 영역(RSM)이 실행 또는 설정될 수 있다.
한편, 호출 저장 영역(RSM)은, RPC Shared Memory로 명명될 수도 있다.
한편, 호스트 드라이버(HD)는, 원격 절차 호출을 위한 공유 메모리(SMR)를 생성할 수 있다. 또한, 호스트 드라이버(HD)는, 컨트롤 페이지 테이블(CPT)를 생성할 수 있다.
한편, 각 가상화 머신(VMA,VMB)의 공유 메모리 드라이버(SMDa,SMDb)은, 공유 메모리(SMR)의 메모리 할당, 해제, 영역 생성 등을 제어할 수 있다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 공유 메모리(SMR)를 통한 원격 절차 호출 방법을 제공할 수 있다.
예를 들어, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, RPC 컨트롤 페이지의 생성 또는 관리할 수 있다.
다른 예로, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 호출자 별로, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 포함하는 원격 절차 호출 채널을 생성 또는 관리할 수 있다.
한편, 호출자(RCA)에 의한 RPC 호출은, 제2 호출 인터페이스(eRCa)를 통해 상호 공유 영역(IVS)에 정보를 쓰고 읽는 것에 의해 수행될 수 있다.
호출자(RCA)가 전달한 파라미터(parameter) 데이터는, 메타 데이터와 함께, 직렬화 없이, 그대로, 상호 공유 영역(IVS)에 복사될 수 있다.
한편, 포인터(pointer) 파라미터인 경우, 포인터가 가리키는 대상의 내용을 호출 저장 영역(RSM)에 복사하고, 호출 저장 영역(RSM)에 포인터가 전달된다.
한편, 호출 저장 영역(RSM)에 존재하는 파라미터 데이터는, 복사 없이 포인터로 전달된다.
한편, 제2 가상화 머신(VMA) 내의 제2 호출 인터페이스(eRCa)는, 상호 공유 영역(IVS)에 호출과 관련한 정보를 기록하고, 제1 가상화 머신(VMB)에 통보하며, 제1 가상화 머신(VMB)은, 상호 공유 영역(IVS) 내의 데이터를 수신할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신(VMB) 내의 제1 호출 인터페이스(eRCb)는, 수신된 데이터에 기초하여 처리된 결과 데이터를 상호 공유 영역(IVS) 내에 기록하고, 제2 가상화 머신(VMA)에 통보하고, 제2 가상화 머신(VMA)은, 상호 공유 영역(IVS)에 기록된 결과 데이터를 수신할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 가상화 머신(VMB) 내의 제1 호출 인터페이스(eRCb) 또는 제2 가상화 머신(VMA) 내의 제2 호출 인터페이스(eRCa)는, 상호 공유 영역(IVS)의 용량을 초과하는 데이터를, 공유 메모리(SMR) 내의 별도 영역(RSM)에 저장하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제2 호출 인터페이스(eRCa)는, 호출자(RCA)가 전달한 파라미터 데이터인 경우, 파라미터 데이터와 메타 데이터를 상호 공유 영역(IVS)으로 복사하도록 제어하고, 포인터 파라미터인 경우, 포인터에 대응하는 데이터를 공유 메모리(SMR) 내의 호출 저장 영역(RSM)에 전달하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 공유 메모리(SMR) 내의 컨트롤 페이지(RCP)를 생성 또는 관리하거나, 상호 공유 영역(IVS)을 생성 또는 관리하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 공유 메모리(SMR) 내의 컨트롤 페이지 테이블(CPT), 컨트롤 페이지(RCP)를 통해, 공유 메모리(SMR) 외부의 호스트 드라이버(HD)와 상호 작용하여, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 호스트 드라이버(HD)를 통해, 컨트롤 페이지(RCP)를 생성하거나 삭제하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 컨트롤 페이지(RCP)를 생성하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 원격 절차 호출 채널을 생성하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 상호 공유 영역(IVS)을 초과하는 사이즈의 데이터를, 호출 저장 영역(RSM)에 저장하도록 제어하고, 호출 저장 영역(RSM)의 주소를 상호 공유 영역(IVS)에 기록하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
한편, 제1 호출 인터페이스(eRCb) 또는 제2 호출 인터페이스(eRCa)는, 상호 공유 영역(IVS)을 초과하는 사이즈의 데이터를, 호출 저장 영역(RSM)에 저장하도록 제어하고, 호출 저장 영역(RSM)의 주소를 상호 공유 영역(IVS)에 기록하도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
도 12 내지 도 16d는 도 11의 설명에 참조되는 도면이다.
먼저, 도 12는 도 11의 공유 메모리 내부의 동작 설명에 참조되는 도면이다.
도면을 참조하면, 컨트롤 페이지(RCP)는, 공유 메모리(SMR) 내에 존재하며, 원격 절차 호출 서비스 제공자인 피호출자(RCE)에 대응한다.
즉, 원격 절차 호출 서비스 제공자인 피호출자(RCE)의 개수 만큼 컨트롤 페이지(RCP)가 만들어진다.
한편, 컨트롤 페이지(RCP)는, 제1 호출 인터페이스(eRCb)가 호스트 드라이버(evRPC host driver)(HD)를 통해, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)으로 이루어지는 원격 절차 호출 채널을 생성 또는 제거하도록 제어할 수 있다.
한편, 컨트롤 페이지(RCP)는, 제1 호출 인터페이스(eRCb)가 호스트 드라이버(HD)를 통해, 호출 저장 영역(RSM)으로부터 메모리를 할당 또는 반환할 수 있도록 한다.
한편, 원격 절차 호출 채널은, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)로 이루어지며, 원격 절차 호출 서비스 이용자인 호출자(RCA)에 대응한다.
즉, 원격 절차 호출 서비스 이용자인 호출자(RCA)의 개수 만큼 원격 절차 호출 채널이 만들어진다.
한편, 상호 공유 영역(IVS)은, 원격 절차 호출 채널의 구성 요소의 하나이다. 제1 호출 인터페이스(eRCb)는, 요청받은 원격 절차 호출 정보와 결과 정보를 상호 공유 영역(IVS)에 기록하고 상호 공유 영역(IVS)을 통해 상대편에 통지할 수 있다.
원격 절차 호출 정보는, 대상 및 요청 관련 정보로서, 예를 들어, 전화 번호 질의, 대상의 이름 정보를 포함할 수 있다. 결과 정보는, 예를 들어, 전화 번호 정보를 포함할 수 있다.
호출 저장 영역(RSM)은, 원격 절차 호출 채널의 구성 요소의 하나로, 피호출자(RCE)와 호출자(RCA)가 공유한다.
호출 저장 영역(RSM)은, 원격 절차 호출에 필요한 데이터 크기가 큰 경우 등에 사용된다.
제1 호출 인터페이스(eRCb)가 컨트롤 페이지(RCP)를 통해 호스트 드라이버(HD)에 요청하는 경우, 호출 저장 영역(RSM)의 메모리 할당 또는 반환이 이루어진다.
예를 들어, 화면 캡처를 요청한 경우, 화면 캡쳐 데이터는 상대적으로 데이터 크기가 크다. 이런 경우, 호출 저장 영역(RSM)에 메모리를 할당 받아, 화면 캡쳐 데이터를 저장하고, 저장한 주소를 상호 공유 영역(IVS)에 기록하여 전달할 수 있다. 이에, 화면 캡처를 요청한 쪽에서는 해당 메모리에 접근하여 화면 캡쳐 데이터를 사용할 수 있다.
구체적으로, 제2 가상화 머신(VMA) 내의 호출자(RCA)가 화면 캡처를 요청한 경우, 제1 가상화 머신(VMB)은, 화면 캡쳐 데이터를, 호출 저장 영역(RSM)에 저장하도록 제어하고, 호출 저장 영역(RSM)의 주소를 상호 공유 영역(IVS)에 기록하도록 제어할 수 있다. 이에 따라, 호출 저장 영역(RSM)과 상호 공유 영역(IVS)을 이용하여, 제2 가상화 머신(VMA)에서 제1 가상화 머신(VMB)으로 화면 캡쳐 데이터를 간편하고 신속하게 전송할 수 있게 된다. 또한, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
도 13a는 원격 절차 호출 서비스의 등록 및 삭제를 설명하기 위해 참조되는 도면이다.
도면을 참조하면, 원격 절차 호출 서비스의 등록을 위해, 호스트 드라이버(HD)는, 호출 저장 영역(RSM)에 컨트롤 페이지 테이블(CPT)를 생성한다(STa1).
다음, 피호출자(RCE) 측의 제1 호출 인터페이스(eRCb)는, 제1 공유 메모리 드라이버(SMDb)를 통해 컨트롤 페이지 테이블(CPT)의 주소를 가져온다(STa2).
다음, 피호출자(RCE)는 원격 절차 호출을 등록한다(STa3).
구체적으로, 제1 호출 인터페이스(eRCb)는, 원격 절차 호출 테이블에 피호출자(RCE)로부터 등록 요청 받은 원격 절차 호출을 기록한다.
그리고, 제1 호출 인터페이스(eRCb)는, 컨트롤 페이지 테이블(CPT)을 통해 원격 절차 호출 컨트롤 페이지(RCP)의 생성을 요청한다.
그리고, 호스트 드라이버(HD)는, 호출 저장 영역(RSM)에 컨트롤 페이지(RCP)를 생성하고, 관련 정보를 컨트롤 페이지 테이블(CPT)에 기록한다.
한편, 등록한 원격 절차 호출 서비스의 삭제를 위해, 컨트롤 페이지 테이블(CPT)을 통해 삭제를 요청하고, 이 요청에 따라 호스트 드라이버(HD)가 컨트롤 페이지(RCP)를 삭제하고 컨트롤 페이지 테이블(CPT)을 갱신한다.
즉, 제1 가상화 머신(VMB)은, 공유 메모리(SMR) 내의 컨트롤 페이지 테이블(CPT)에 대한 데이터를 수신하고, 수신된 컨트롤 페이지 테이블(CPT)에 대한 데이터에 기초하여, 제1 원격 절차 호출 서비스를 등록할 수 있다.
도 13b는 원격 절차 호출 채널의 생성 및 삭제를 설명하기 위해 참조되는 도면이다.
도면을 참조하면, 원격 절차 호출 채널의 생성을 위해, 원격 절차 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 제2 공유 메모리 드라이버(SMDa)를 통해, 컨트롤 페이지 테이블(CPT)의 주소를 가져온다(STb1).
다음, 원격 절차 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 컨트롤 페이지 테이블(CPT)를 통해 컨트롤 페이지(RCP) 주소를 가져온다(STb2).
다음, 원격 절차 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 컨트롤 페이지(RCP)를 통해, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 포함하는 원격 절차 호출 채널의 생성을 요청한다(STb3).
다음, 호스트 드라이버(HD)는, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 생성하고, 컨트롤 페이지(RCP)에 해당 정보를 기록한다(STb4).
다음, 피호출자(RCE) 측 제1 호출 인터페이스(eRCb)는, 컨트롤 페이지(RCP)에서 생성된 채널 정보를 가져온다(STb5).
예를 들어, 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 포함하는 원격 절차 호출 채널의 생성이 완료되는 경우, 피호출자(RCE) 측 제1 호출 인터페이스(eRCb)는, 채널 생성을 통보 받아, 컨트롤 페이지(RCP)에서 생성된 채널 정보를 수신할 수 있다.
한편, 원격 절차 호출 채널의 삭제를 위해, 생성 과정과 동일하게 진행되나, 컨트롤 페이지(RCP)를 통해, 원격 절차 호출 채널의 삭제를 요청하고, 호스트 드라이버(HD)는, 해당 원격 절차 호출 채널을 삭제하고, 컨트롤 페이지(RCP)를 갱신한다.
다음, 원격 절차 호출의 서버측인 피호출자(RCE) 측의 제1 호출 인터페이스(eRCb)는, 컨트롤 페이지(RCP)에서 삭제된 컨트롤 페이지(RCP) 채널 정보를 가져온다.
즉, 제2 가상화 머신(VMA)은, 공유 메모리(SMR) 내에 상호 공유 영역(IVS)과 호출 저장 영역(RSM)을 포함하는 원격 절차 호출 채널을 생성하도록 공유 메모리(SMR)에 요청하고, 생성된 원격 절차 호출 채널에 대한 정보를 수신할 수 있다.
도 13c는 제1 모드의 원격 절차 호출을 설명하기 위해 참조되는 도면이다.
도면을 참조하면, 제1 모드는, 일반 모드의 원격 절차 호출로서, 원격 절차 호출에 대응하는 데이터의 크기가, 상호 공유 영역(IVS)의 용량 이하인 경우를 예시한다.
먼저, 원격 절차 호출을 위해 호출자(RCA)는, 제2 호출 인터페이스(eRCa)에 원격 절차 호출을 요청한다(STc1).
다음, 원격 절차 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 호출 관련 정보를 상호 공유 영역(IVS)에 기록하고 호출을 요청한다(STc2).
여기서, 호출 관련 정보는, 함수 식별자(고유의 숫자 혹은 문자열), 함수 호출 인자 개수, 첫 번째 인자의 offset, 또는 함수 인자 등을 포함할 수 있다.
다음, 피호출자(RCE) 측 제1 호출 인터페이스(eRCb)는, 호출 요청을 수신하고, 상호 공유 영역(IVS)로부터 정보를 읽어, 원격 절차 호출 테이블로부터 호출해야 함수 정보를 가져오고, 상호 공유 영역(IVS)에 기록된 인자와 함께 함수를 호출한다(STc3).
이때, 반환 값이 있는 경우, 상호 공유 영역(IVS)의 반환 값을 위한 영역의 주소를 함께 제공하며, 피호출자(RCE)는 이곳에 반환 값을 직접 저장할 수 있다.
다음, 호출이 완료되면, 피호출자(RCE) 측 제1 호출 인터페이스(eRCb)는, 상호 공유 영역(IVS)을 통해, 호출 완료를 통보하고, 원격 절차 호출을 수행한 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 호출 완료를 수신하면 원격 절차 호출자(RCA)에 통보한다(STc4).
예를 들어, 동기식 호출인 경우, 호출 완료를 수신할 때까지 원격 절차 호출자(RCA)는, 원격 절차 호출 요청에서 블록되어 있고, 호출 완료 통보 수신 시 반환된다.
다른 예로, 비동기식 호출인 경우, 원격 절차 호출자(RCA)의 원격 절차 호출 요청은 즉시 반환되고, 호출 완료 통보 수신 시 별도 문맥을 통해 결과를 전달한다.
도 13c와 같은 방식에 의해, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다. 또한, 데이터 공유와 원격 절차 호출을 통합할 수 있게 된다.
도 13d는 제2 모드의 원격 절차 호출을 설명하기 위해 참조되는 도면이다.
도면을 참조하면, 제2 모드는, 일반 모드의 원격 절차 호출로서, 원격 절차 호출에 대응하는 데이터의 크기가, 상호 공유 영역(IVS)의 용량 초과인 경우를 예시한다.
먼저, 원격 절차 호출자(RCA)는, 제2 호출 인터페이스(eRCa)에 메모리 할당을 요청한다(STd1).
다음, 원격 절차 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 컨트롤 페이지(RCP)를 통해, 해당 채널의 호출 저장 영역(RSM)으로 메모리 할당을 요청한다(STd2).
다음, 호스트 드라이버(HD)는, 해당 채널의 호출 저장 영역(RSM)에 메모리를 할당하여 그 주소를 반환한다(STd3).
다음, 원격 절차 호출자(RCA)는, 할당 받은 메모리에 데이터를 직접 쓴다(STd4).
다음, 원격 절차 호출자(RCA)는, 제2 호출 인터페이스(eRCa)에 원격 절차 호출을 요청하고, 제2 호출 인터페이스(eRCa)는 앞서의 경우와 같이 원격 절차 호출 요청을 처리한다. 단, 이 때, 함수 인자는, 호출 저장 영역(RSM)의 메모리 주소이다(STd5).
다음, 호출 결과 반환 과정은 도 13c와 동일하다(STd6).
즉, 도 13c와 같이, 피호출자(RCE) 측 제1 호출 인터페이스(eRCb)는, 호출 요청을 수신하고, 호출 저장 영역(RSM)과, 상호 공유 영역(IVS)로부터 정보를 읽어, 원격 절차 호출 테이블로부터 호출해야 함수 정보를 가져오고, 상호 공유 영역(IVS)에 기록된 인자와 함께 함수를 호출한다.
이때, 반환 값이 있는 경우, 상호 공유 영역(IVS)의 반환 값을 위한 영역의 주소를 함께 제공하며, 피호출자(RCE)는 이곳에 반환 값을 직접 저장할 수 있다.
다음, 호출이 완료되면, 피호출자(RCE) 측 제1 호출 인터페이스(eRCb)는, 상호 공유 영역(IVS)을 통해, 호출 완료를 통보하고, 원격 절차 호출을 수행한 호출자(RCA) 측 제2 호출 인터페이스(eRCa)는, 호출 완료를 수신하면 원격 절차 호출자(RCA)에 통보한다.
한편, 도 13d와 같은 방식에 의해, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에, 상호 공유 영역(IVS)의 용량을 초과하는 데이터도, 전송 또는 공유할 수 있게 된다. 나아가, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다. 또한, 데이터 공유와 원격 절차 호출을 통합할 수 있게 된다.
도 14a와 도 14b는 부팅 이후 원격 절차 호출이 수행되는 것을 예시하는 도면이다.
먼저, 도 14a는 서버 가상화 머신(520)과 게스트 가상화 머신(530) 사이에, 네트워크를 이용하여, 화면 표시 서비스를 위한 데이터가 전송되는 것이 예시된다.
예를 들어, 서버 가상화 머신(520)과 게스트 가상화 머신(530) 사이에, 화면 표시 서비스 제공을 위해, 게스트 가상화 머신(530)은, 네트워크를 이용하여, 서버 가상화 머신(520)으로 데이터를 전송할 수 있다.
구체젝으로, 게스트 가상화 머신(530)은, 모든 네트워크 스택(network stack)이 모두 적재된 이후, 서버 가상화 머신(520)으로 데이터를 전송할 수 있다.
그러나, 부팅 이후, 모든 네트워크 스택(network stack)이 모두 적재되려면, 소정 시간이 소요되게 된다.
따라서, 도 14a의 방식에 의하면, 시스템 부팅 초기에 네트워크가 활성화되기 전에는, 원격 절차 호출의 사용이 불가능하다는 단점이 있다.
도 14b는 서버 가상화 머신(520)과 게스트 가상화 머신(530) 사이에, 상호 공유 영역(IVS)과 호출 인터페이스(eRCa,eRCb)를 이용하여, 화면 표시 서비스를 위한 데이터가 전송되는 것이 예시된다.
예를 들어, 서버 가상화 머신(520)과 게스트 가상화 머신(530) 사이에, 화면 표시 서비스 제공을 위해, 게스트 가상화 머신(530)은, 상호 공유 영역(IVS)과 호출 인터페이스(eRCa,eRCb)를 이용하여, 서버 가상화 머신(520)으로 데이터를 전송할 수 있다.
특히, 도 11에서 도 13d에서 기술한 바와 같이, 게스트 가상화 머신(530)은, 상호 공유 영역(IVS)과 호출 인터페이스(eRCa,eRCb)를 이용하여, 서버 가상화 머신(520)으로 데이터를 전송할 수 있다.
도 14a와 비교하여, 부팅 이후, 모든 네트워크 스택(network stack)이 모두 적재되지 않아도 되므로, 소정 시간 이후가 아니라, 부팅 이후 바로, 상호 공유 영역(IVS)과 호출 인터페이스(eRCa,eRCb)를 이용하여, 서버 가상화 머신(520)으로 데이터를 전송할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다. 또한, 데이터 공유와 원격 절차 호출을 통합할 수 있게 된다.
한편, 도 14b의 게스트 가상화 머신(530)은, 도 11에서 도 13d의 제2 가상화 머신(VMA)에 대응하며, 도 14b의 서버 가상화 머신(520)은, 도 11에서 도 13d의 제1 가상화 머신(VMB)에 대응할 수 있다.
즉, 제2 가상화 머신(VMA)의 원격 절차 호출에 따라, 제1 가상화 머신(VMB)은, 부팅 이후, 바로, 상호 공유 영역(IVS)을 이용하여, 제2 가상화 머신(VMA)으로 데이터가 전송되도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 원격 절차 호출시에 호출과 응답 지연 시간을 단축할 수 있게 된다.
도 14c와 도 14d는 센싱 데이터를 반복적으로 수신하는 경우의 원격 절차 호출이 수행되는 것을 예시하는 도면이다.
먼저, 도 14c는 반복적인 센싱 데이터를 수신하는 시스템의 일예를 예시한다.
도면을 참조하면, 하이퍼바이저(505) 상에, 가상 네트워크 드라이버들, TCP/IP 레이어들, 소켓 레이어들, 직렬화, 역직렬화 등, 네트워크를 이용하여, 반복적인 센싱 데이터를 수신하는 경우, 여러 절차를 거쳐야 하므로, 리소스 낭비 및 오버헤드(overhead)가 발생되는 단점이 있다.
도 14d는 본 발명의 실시예에 따른 시스템을 도시한 도면이다.
도면을 참조하면, 본 발명의 실시예에 따른 신호 처리 장치(170)에서 실행되는 시스템은, 하이퍼바이저(505) 상에, 공유 메모리 드라이버들(SMDa,SMDb), 호출 인터페이스(eRCa,eRCb)들을 이용하여, 반복적인 센싱 데이터를 수신할 수 있다.
이러한 방식에 의하면, 공유 메모리(SMR) 내에 원격 절차 호출을 위한 상호 공유 영역(IVS)을 이용하여, 반복적인 센싱 데이터를 수신하므로, 리소스 저감 및 오버헤드(overhead)를 저감할 수 있게 된다.
한편, 서버 가상화 머신(520)인 제1 가상화 머신(VMB)은, 센싱 데이터를 반복적으로 수신하며, 상호 공유 영역(IVS)을 이용하여, 게스트 가상화 머신(530)인 제2 가상화 머신(VMA)으로 센싱 데이터가 전송되도록 제어할 수 있다. 이에 따라, 복수의 가상화 머신(VMA,VMB) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(VMA,VMB) 사이에서 센싱 데이터 전송시의 리소스를 효율적으로 사용할 수 있게 된다.
한편, 제2 가상화 머신(530)은 제1 디스플레이(180a)를 위해 동작하며, 프로세서(175)는, 제2 디스플레이(180b)를 위해 제3 가상화 머신(540)을 더 실행하며, 제2 가상화 머신(530)은, 공유 메모리(SMR) 내의 제2 상호 공유 영역(IVS)을 이용하여, 음악 재생 정보를 제3 가상화 머신(530)으로 요청하며, 제2 상호 공유 영역(IVS)에 기록된 음악 재생 정보를 수신하여, 음악 재생 정보를 제1 디스플레이(180a)에 표시하도록 제어할 수 있다. 음악 재생 정보 전송과 관련하여, 도 15a 내지 도 15d를 참조하여 기술한다.
도 15a 내지 도 15d는 클러스터 디스플레이에서 AVN 디스플레이에 음악 재생 정보를 요청하는 경우를 설명하기 위해 참조되는 도면이다.
도 15a는 제1 디스플레이(180a)를 위해 동작하는 제2 가상화 머신(530)에서, 제2 디스플레이(180b)를 위해 동작하는 제3 가상화 머신(540)으로, 음악 재생 여부를 질의하는 것을 예시한다.
예를 들어, 제2 가상화 머신(530) 내의 휴먼 머신 인터페이스(HMI)는, 원격 절차 호출을 통해, 제3 가상화 머신(540)에서 실행되는 미디어 서비스에 재생 여부와 관련한 호출을 전달한다(STf1).
도 15b는 제2 가상화 머신(530)에서, 제3 가상화 머신(540)으로, 재생 정보의 주기적 갱신 요청하는 것을 예시한다.
예를 들어, 제2 가상화 머신(530) 내의 휴먼 머신 인터페이스(HMI)는, 원격 절차 호출을 통해, 제3 가상화 머신(540)에서 실행되는 미디어 서비스에 재생 정보의 주기적인 갱신을 위한 호출을 전달한다(STf2).
도 15c는 제3 가상화 머신(540)에서, 제2 가상화 머신(530)으로, 주기적 재생 정보를 갱신하는 것을 예시한다.
예를 들어, 제3 가상화 머신(540)에서 실행되는 미디어 서비스는, 제2 가상화 머신(530) 내의 휴먼 머신 인터페이스(HMI)로, 원격 절차 호출을 통해, 주기적 재생 정보를 갱신을 위한 호출을 전달한다(STf3).
도 15d는 클러스터 디스플레이인 제1 디스플레이(180a)에, 지도 정보(1590), 운행 정보(1592) 외에 추가로 음악 재생 정보(1594)를 포함하는 화면(1580)이 표시되는 것을 예시한다.
이에 따라, 복수의 가상화 머신(530,540) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(530,540) 사이에서 음악 재생 정보 전송시의 리소스를 효율적으로 사용할 수 있게 된다. 나아가, 가상화 머신의 개수가 증가되더라도, 가상화 머신 사이에 신속한 상호 작용을 구현할 수 있게 된다.
한편, 제2 가상화 머신(VMA)은 제1 디스플레이(180a)를 위해 동작하며, 프로세서(175)는, 제2 디스플레이(180b)를 위해 제3 가상화 머신을 더 실행하며, 제2 가상화 머신(VMA)은, 공유 메모리(SMR) 내의 제2 상호 공유 영역(IVS)을 이용하여, 화면 테마 정보를 제3 가상화 머신으로 요청하며, 제2 상호 공유 영역(IVS)에 기록된 화면 테마 정보를 수신하여, 화면 테마 정보를 제1 디스플레이(180a)에 표시하도록 제어할 수 있다.
화면 테마 정보와 관련하여, 도 16a 내지 도 16d를 참조하여 기술한다.
도 16a 내지 도 16d는 클러스터 디스플레이(180a)와 AVN 디스플레이(108b)에 화면 테마 설정이 수행되는 경우를 설명하기 위해 참조되는 도면이다.
도 16a는 제1 디스플레이(180a)를 위해 동작하는 제2 가상화 머신(530)에서, 제2 디스플레이(180b)를 위해 동작하는 제3 가상화 머신(540)으로, 화면 테마 정보를 요청하는 것을 예시한다.
예를 들어, 제2 가상화 머신(530) 내의 휴먼 머신 인터페이스(HMI)는, 원격 절차 호출을 통해, 제3 가상화 머신(540)에서 실행되는 설정 서비스에 화면 테마 정보와 관련한 호출을 전달한다(STg1).
도 16b는 제3 가상화 머신(540)에서, 제2 가상화 머신(530)으로, 화면 테마 변경을 통보하는 것을 예시한다.
예를 들어, 제3 가상화 머신(540)에서 실행되는 설정 서비스는, 제2 가상화 머신(530) 내의 휴먼 머신 인터페이스(HMI)로, 원격 절차 호출을 통해, 화면 테마 변경을 위한 호출을 전달한다(STg2).
도 16c는 클러스터 디스플레이인 제1 디스플레이(180a)에, 지도 정보(1590), 운행 정보(1592), 음악 재생 정보(1594)를 포함하는 화면(1580)이 표시되는 것을 예시한다.
특히, 화면(1580)이 제1 화면 테마 모드에 따라 표시되는 것을 예시한다.
도 16d는 클러스터 디스플레이인 제1 디스플레이(180a)에, 지도 정보(1690), 운행 정보(1692), 음악 재생 정보(1694)를 포함하는 화면(1680)이 표시되는 것을 예시한다.
특히, 화면(1680)이, 제3 가상화 머신(540)으로부터의 화면 테마 변경에 따라, 제1 화면 테마 모드와 다른 제2 화면 테마 모드에 따라 표시되는 것을 예시한다.
이에 따라, 복수의 가상화 머신(530,540) 사이에서 리소스를 효율적으로 사용할 수 있게 된다. 특히, 복수의 가상화 머신(530,540) 사이에서 화면 테마 정보 전송시의 리소스를 효율적으로 사용할 수 있게 된다.
한편, 이상에서는 본 발명의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안될 것이다.

Claims (20)

  1. 차량에 장착되는 디스플레이를 위한 신호 처리를 수행하는 프로세서를 포함하는 신호 처리 장치에 있어서,
    상기 프로세서는,
    상기 프로세서 내의 하이퍼바이저 상에서, 복수의 가상화 머신을 실행하며,
    상기 복수의 가상화 머신 중 제1 가상화 머신과, 제2 가상화 머신은,
    상기 하이퍼바이저 내의 공유 메모리 내에 원격 절차 호출을 위한 상호 공유 영역을 공유하며,
    상기 제1 가상화 머신은,
    상기 제2 가상화 머신의 호출자에 대응하여 데이터를 수신하는 피호출자와, 상기 상호 공유 영역으로의 억세스를 위한 제1 호출 인터페이스를 실행하고,
    상기 제2 가상화 머신은,
    상기 원격 절차 호출을 위한 호출자와, 상기 상호 공유 영역으로의 억세스를 위한 제2 호출 인터페이스를 실행하는 것을 특징으로 하는 신호 처리 장치.
  2. 제1항에 있어서,
    상기 제2 가상화 머신은,
    상기 상호 공유 영역에 호출과 관련한 정보를 기록하고, 상기 제1 가상화 머신에 통보하며,
    상기 제1 가상화 머신은,
    상기 상호 공유 영역 내의 데이터를 수신하는 것을 특징으로 하는 신호 처리 장치.
  3. 제2항에 있어서,
    상기 제1 가상화 머신은,
    상기 수신된 데이터에 기초하여 처리된 결과 데이터를 상기 상호 공유 영역 내에 기록하고, 상기 제2 가상화 머신에 통보하고,
    상기 제2 가상화 머신은,
    상기 상호 공유 영역에 기록된 결과 데이터를 수신하는 것을 특징으로 하는 신호 처리 장치.
  4. 제1항에 있어서,
    상기 제1 가상화 머신 또는 상기 제2 가상화 머신은,
    상기 상호 공유 영역의 용량을 초과하는 데이터를, 상기 공유 메모리 내의 별도 영역에 저장하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  5. 제1항에 있어서,
    상기 제2 호출 인터페이스는,
    상기 호출자가 전달한 파라미터 데이터인 경우, 상기 파라미터 데이터와 메타 데이터를 상기 상호 공유 영역으로 복사하도록 제어하고,
    포인터 파라미터인 경우, 상기 포인터에 대응하는 데이터를 상기 공유 메모리 내의 호출 저장 영역에 전달하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  6. 제1항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 공유 메모리 내의 컨트롤 페이지를 생성 또는 관리하거나,
    상기 상호 공유 영역을 생성 또는 관리하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  7. 제1항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  8. 제1항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 공유 메모리 내의 컨트롤 페이지 테이블, 컨트롤 페이지를 통해, 상기 공유 메모리 외부의 호스트 드라이버와 상호 작용하여, 상기 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하거나 삭제하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  9. 제8항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 호스트 드라이버를 통해, 상기 컨트롤 페이지를 생성하거나 삭제하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  10. 제8항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 컨트롤 페이지를 생성하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  11. 제7항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 원격 절차 호출 관련 서비스의 제공자의 개수에 대응하는 개수의 원격 절차 호출 채널을 생성하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  12. 제7항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 상호 공유 영역을 초과하는 사이즈의 데이터를, 상기 호출 저장 영역에 저장하도록 제어하고, 상기 호출 저장 영역의 주소를 상기 상호 공유 영역에 기록하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  13. 제7항에 있어서,
    상기 제1 호출 인터페이스 또는 상기 제2 호출 인터페이스는,
    상기 상호 공유 영역을 초과하는 사이즈의 데이터를, 상기 호출 저장 영역에 저장하도록 제어하고, 상기 호출 저장 영역의 주소를 상기 상호 공유 영역에 기록하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  14. 제7항에 있어서,
    상기 제1 호출 인터페이스는,
    화면 쳐캡 데이터인 경우, 상기 호출 저장 영역에 저장하도록 제어하고, 상기 호출 저장 영역의 주소를 상기 상호 공유 영역에 기록하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  15. 제1항에 있어서,
    상기 제2 가상화 머신은,
    상기 공유 메모리 내에 상기 상호 공유 영역과 호출 저장 영역을 포함하는 원격 절차 호출 채널을 생성하도록 상기 공유 메모리에 요청하고,
    상기 생성된 원격 절차 호출 채널에 대한 정보를 수신하는 것을 특징으로 하는 신호 처리 장치.
  16. 제1항에 있어서,
    상기 제1 가상화 머신은,
    부팅 이후, 상기 상호 공유 영역을 이용하여, 상기 제2 가상화 머신으로 데이터가 전송되도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  17. 제1항에 있어서,
    상기 제1 가상화 머신은,
    센싱 데이터를 반복적으로 수신하며, 상기 상호 공유 영역을 이용하여, 상기 제2 가상화 머신으로 상기 센싱 데이터가 전송되도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  18. 제1항에 있어서,
    상기 제2 가상화 머신은 제1 디스플레이를 위해 동작하며,
    상기 프로세서는,
    제2 디스플레이를 위해 제3 가상화 머신을 더 실행하며,
    상기 제2 가상화 머신은,
    상기 공유 메모리 내의 제2 상호 공유 영역을 이용하여, 음악 재생 정보를 상기 제3 가상화 머신으로 요청하며, 상기 제2 상호 공유 영역에 기록된 음악 재생 정보를 수신하여, 상기 음악 재생 정보를 상기 제1 디스플레이에 표시하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  19. 제1항에 있어서,
    상기 제2 가상화 머신은 제1 디스플레이를 위해 동작하며,
    상기 프로세서는,
    제2 디스플레이를 위해 제3 가상화 머신을 더 실행하며,
    상기 제2 가상화 머신은,
    상기 공유 메모리 내의 제2 상호 공유 영역을 이용하여, 화면 테마 정보를 상기 제3 가상화 머신으로 요청하며, 상기 제2 상호 공유 영역에 기록된 화면 테마 정보를 수신하여, 상기 화면 테마 정보를 상기 제1 디스플레이에 표시하도록 제어하는 것을 특징으로 하는 신호 처리 장치.
  20. 적어도 하나의 디스플레이;
    디스플레이를 위한 신호 처리를 수행하는 프로세서를 포함하는 신호 처리 장치;를 구비하고,
    상기 신호 처리 장치는, 제1항 내지 제19항 중 어느 한 항의 신호 처리 장치를 포함하는 것을 특징으로 하는 차량용 디스플레이 장치.
PCT/KR2022/000619 2022-01-13 2022-01-13 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치 WO2023136373A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/KR2022/000619 WO2023136373A1 (ko) 2022-01-13 2022-01-13 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2022/000619 WO2023136373A1 (ko) 2022-01-13 2022-01-13 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치

Publications (1)

Publication Number Publication Date
WO2023136373A1 true WO2023136373A1 (ko) 2023-07-20

Family

ID=87279251

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/000619 WO2023136373A1 (ko) 2022-01-13 2022-01-13 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치

Country Status (1)

Country Link
WO (1) WO2023136373A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060071307A (ko) * 2004-12-21 2006-06-26 마이크로소프트 코포레이션 가상 기기들을 위한 프로세서 토폴로지를 노출시키는시스템 및 방법
KR20110139151A (ko) * 2010-06-21 2011-12-28 인텔 코오퍼레이션 다수의 가상 머신들 사이에서 네트워크 인터페이스를 공유하기 위한 방법
JP6523298B2 (ja) * 2014-01-06 2019-05-29 ジョンソン コントロールズ テクノロジー カンパニーＪｏｈｎｓｏｎ Ｃｏｎｔｒｏｌｓ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏｍｐａｎｙ コンピュータシステムと車両インターフェースシステム
KR20200086212A (ko) * 2019-01-07 2020-07-16 리얼텍 세미컨덕터 코퍼레이션 가상 머신, 전자 장치 및 비 일시적 컴퓨터 판독 가능 저장 매체를 위한 통신 방법
JP2021166006A (ja) * 2020-04-08 2021-10-14 富士通株式会社 情報処理プログラム、情報処理方法、および情報処理装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060071307A (ko) * 2004-12-21 2006-06-26 마이크로소프트 코포레이션 가상 기기들을 위한 프로세서 토폴로지를 노출시키는시스템 및 방법
KR20110139151A (ko) * 2010-06-21 2011-12-28 인텔 코오퍼레이션 다수의 가상 머신들 사이에서 네트워크 인터페이스를 공유하기 위한 방법
JP6523298B2 (ja) * 2014-01-06 2019-05-29 ジョンソン コントロールズ テクノロジー カンパニーＪｏｈｎｓｏｎ Ｃｏｎｔｒｏｌｓ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏｍｐａｎｙ コンピュータシステムと車両インターフェースシステム
KR20200086212A (ko) * 2019-01-07 2020-07-16 리얼텍 세미컨덕터 코퍼레이션 가상 머신, 전자 장치 및 비 일시적 컴퓨터 판독 가능 저장 매체를 위한 통신 방법
JP2021166006A (ja) * 2020-04-08 2021-10-14 富士通株式会社 情報処理プログラム、情報処理方法、および情報処理装置

Similar Documents

Publication Publication Date Title
WO2019132344A1 (en) Method for controlling earpiece and electronic device for supporting the same
WO2022181960A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2016047887A1 (ko) 이동단말기의 운용 체제 전환장치 및 방법, 차량 및 그 차량의 운용 체제 전송장치 및 방법
WO2020231083A1 (ko) 열전달 구조를 포함하는 전자 장치
WO2015093665A1 (ko) 전자기기 및 전자기기의 제어방법
WO2017080403A1 (zh) 投影设备控制方法、投影设备及智能终端
WO2019066343A1 (en) METHOD AND DEVICE FOR COMMUNICATION BETWEEN ELECTRONIC DEVICES
WO2019194428A1 (ko) 외부 전자 장치의 키를 공유하는 전자 장치 및 전자 장치의 동작 방법
WO2023136373A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2024034709A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023191195A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2024034708A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023136374A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2022103093A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023195559A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023113078A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023136376A1 (ko) 차량용 디스플레이 장치
WO2023113079A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2024071476A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2024085283A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023239009A1 (ko) 차량의 신호 처리 장치 및 이를 구비하는 차량용 통신 장치용 통신 장치
WO2024071475A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 디스플레이 장치
WO2023136369A1 (ko) 차량용 디스플레이 장치
WO2024034752A1 (ko) 신호 처리 장치, 및 이를 구비하는 차량용 증강현실 장치
WO2022098103A1 (ko) 차량용 디스플레이 장치

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: 22920706

Country of ref document: EP

Kind code of ref document: A1