Patent Description:
Vehicles are gradually moving to a higher level of computerization. Most vehicle tasks, functions, and tasks are currently under computer control or can be monitored by a computing device. As a digital age is emerging, consumers require similarity between a mobile phone and a tablet computer.

For example, General Motors Company and Ford Motor Company are developing vehicle infotainment systems with more dynamic user interfaces. For example, in a Cadillac infotainment system, Cadillac User Experience (CUE™), a vehicle infotainment system having an intelligent user interface with touch and haptic feedback, natural language voice interaction, proximity detection, and buttons and controls is integrated, and thus more in-vehicle information, communication navigation, and entertainment are integrated and simplified and are adjusted for driving use. Ford Motor Company has developed a SYNC™ system and a MYFORD™ system, which provide similar functionality to the CUE™, and vehicle application storage for games and other types of applications. The MYFORD™ system provides an open architecture that allows developers to develop software in which custom displays can be executed on web-based cars.

However, carmakers may have limitations in integrating passenger's personal electronic devices such as smart phones, tablet computers, and laptop computers with in-vehicle computing systems.

<CIT> relates to methods, systems and media for binary compatibility. U2013167159A1 relates to a mobile computing device with a mobile operating system and personal computer or vehicle processing module operating system running concurrently and independently on a shared kernel without virtualization. <CIT> relates to a sensor abstraction layer for U-health app development in Android based smartphones.

Embodiments of the present disclosure are directed to providing a vehicle software control device in which a first application executed on a different operating system is utilizable.

Further, embodiments of the present disclosure are directed to providing a vehicle software control device in which a first application is executable without any performance degradation.

It should be noted that objects of the present disclosure are not limited to the above-described objects, and other objects of the present disclosure will be apparent to those skilled in the art from the following descriptions.

The invention is defined as set out in the appended claims.

Viewed from a first aspect, there is provided a vehicle software control device comprising:.

One aspect of the present disclosure provides a vehicle software control device which includes hardware, a kernel connected to the hardware and configured to execute a first operating system, a system library connected to the kernel, a first connecting unit configured to connect a library for a second operating system different from the first operating system to the system library, and a first application executed on the second operating system.

The first connecting unit may include a first calling unit which opens a driver in the system library, and the system library may include a second calling unit which opens a device driver in the kernel which performs the same function as that of the driver in the system library.

The first calling unit and the second calling unit may include a hardware abstraction layer.

The kernel may use a hardware driver opened by the second calling unit to perform a call for accessing the hardware through an application program interface (API).

The vehicle software control device may further include a first application library including a library for executing the first application, a conversion unit configured to convert the library for executing the first application so as to interface with the library of the system library, and a transmission unit configured to transmit the converted library to the system library.

A system file of the first connecting unit may include the same path information as that of a system file of the kernel.

The kernel may provide a control signal to the hardware.

The first operating system and the second operating system may be Linux-based operating systems.

The hardware may include a control unit and a sensor of a vehicle.

According to the embodiments, a vehicle software control device executed on a different operating system can be implemented.

Further, it is possible to provide improved compatibility which is applicable to all operating systems even when versions of the operating systems applied to hardware vendors are different.

Furthermore, it is possible to manufacture a vehicle software control device in which an application is executable without any performance degradation and which includes a vehicle infotainment system.

Various and advantageous advantages and effects of the present disclosure are not limited to the above descriptions and can be more easily understood in describing a specific embodiment of the present disclosure.

It should be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements are not to be limited by these terms.

Other words used to describe the relationship between elements should be interpreted in a like fashion (i.e., "between" versus "directly between," "adjacent" versus "directly adjacent," etc.).

As used herein, the singular forms "a" and "an" are intended to include the plural forms as well unless the context clearly indicates otherwise. It should be further understood that the terms "comprise," "comprising," "include," and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, parts, and/or combinations thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, parts, and/or combinations thereof.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings, the same or corresponding components are denoted by the same reference numerals regardless of reference numbers, and thus the description thereof will not be repeated.

Embodiments of the present disclosure relate to a vehicle software control device for vehicle infotainment and provide a system environment coupled to the vehicle infotainment in utilizing applications ('apps' in the same sense) such as smartphone applications. However, the scope of the present disclosure is not limited to the embodiments of the present disclosure.

<FIG> is a conceptual diagram showing a vehicle software control device according to an embodiment, <FIG> is a conceptual diagram of hardware according to the embodiment, <FIG> is a conceptual diagram of a kernel according to the embodiment, <FIG> is a conceptual diagram of a first connecting unit according to the embodiment, <FIG> is a diagram for describing an operation of a first calling unit according to the embodiment, and <FIG> is a diagram for describing system files of the first connecting unit according to the embodiment.

Referring to <FIG>, a vehicle software control device <NUM> according to the embodiment may include a vehicle infotainment system. The vehicle software control device <NUM> may include a vehicle console operating system associated with the user's usage, a mobile operating system associated with the user's usage in a mobile environment, and a terminal environment associated with the user's usage in the mobile environment. A plurality of applications may be executed simultaneously and independently on a kernel.

In particular, the vehicle software control device <NUM> according to the embodiment may include hardware <NUM>, a kernel <NUM>, a system library <NUM>, a first connecting unit <NUM>, a first application <NUM>, a second connecting unit <NUM>, and a second application <NUM>.

Referring to <FIG>, the hardware <NUM> may include an exemplary architectural configuration of the hardware <NUM> of the vehicle software control device <NUM> according to the embodiment. Generally, the hardware <NUM> may include a processor <NUM>, a display unit <NUM>, a storage unit <NUM>, a memory unit <NUM>, a control unit <NUM>, and an input-and-output (I/O) device <NUM>.

The processor <NUM> may be a vehicle infotainment-based processor <NUM>. For example, the processor <NUM> may include an Advanced reduced instruction set computer (RISC) Machine (ARM)-based processor <NUM> such as a Texas Instruments OMAP3430, a Marvell PXA320, a Freescale iMX51, or a Qualcomm QSD8650/<NUM>. Further, the processor <NUM> may be, for example, another appropriate ARM-based processor <NUM> on the basis of architecture of an x86-based processor <NUM> or architecture of another processor <NUM> such as architecture of another RISC-based processor <NUM>. However, the present disclosure is not limited thereto, and the processor <NUM> may include various processing devices for performing control.

The display unit <NUM> may be a touch screen display. Further, an application executed on the vehicle may be controlled by a graphic user interface (GUI) implemented by the display unit.

The storage unit <NUM> may store system files and the like, and the memory unit <NUM> may process and store predetermined files and information on control signals.

The control unit <NUM> may control various devices or components in the vehicle. For example, the touch screen display may be controlled by the control unit <NUM>.

The I/O device <NUM> may include ports (not shown) or buttons (not shown) and other user interface components that can be employed in the vehicle software control device <NUM>. For example, the buttons may include a click wheel, a scroll wheel, a QWERTY keyboard, and the like. Further, the other user interface components may include Global Positioning System (GPS) devices, local area network (LAN) connectivity, microphones, speakers, cameras, accelerometers, Memory Stick (MS)/MultiMediaCard (MMC)/Secure Digital (SD)/Secure Digital Input Output (SDIO) card interfaces, and the like. However, the present disclosure is not limited thereto.

In addition, the hardware <NUM> may include a power supply <NUM> and various interface components such as a communication device and the like in addition to the above components. For example, the power supply <NUM> may be connected to a battery. Accordingly, the power supply <NUM> may receive information on an electrical state and the like from the battery. In such a configuration, the power supply <NUM> may manage a power source of the vehicle software control device <NUM>.

Referring to <FIG>, the kernel <NUM> may be connected to the hardware <NUM> to provide control signals to the hardware <NUM>. The kernel <NUM> is a region for managing and controlling most basic functions of the devices which provide functions such as interrupt processing, process management, memory management, file system management, and programming interface. Generally, the kernel <NUM> may be loaded into an inaccessible memory and may be regarded as a type of application program interface (API) for controlling hardware. The hardware <NUM> may perform functions in response to the control signals received from the kernel <NUM>.

In the vehicle software control device <NUM>, the kernel <NUM> may execute an operating system. That is, the operating system may be executed on the kernel <NUM>. In particular, the operating system may be a manager applied to the vehicle software control device <NUM> via an interface with the hardware <NUM> through the kernel <NUM>. For example, in a laptop computer, an operating system may include Linux, Mac OS X, or Windows <NUM>. In addition, a mobile operating system may include Android, Apple iOS (for iPhone and iPad), Microsoft Windows Mobile (replaced with Windows Phone <NUM>), Nokia Symbian, or Palm OS (replaced with HP webOS). Here, the kernel <NUM> will be described below on the assumption that tasks are performed by Linux.

The vehicle software control device <NUM> may request the kernel <NUM> so that the kernel <NUM> may manage central processing unit (CPU) scheduling of the operating system, memory access, and computer resources, such as I/O, of the hardware <NUM>. Further, the operating system may be an operating system of the vehicle infotainment. For example, the operating system may be any one of QNX, GENIVI, and Automotive Grade Linux (AGL), but the present disclosure is not limited thereto.

Further, the operating system may perform system calls through the kernel <NUM> interface without a virtual memory or I/O access by virtualization even when the hardware <NUM> is not present. However, the present disclosure is not limited thereto.

Further, in an embodiment, the kernel <NUM> may be a Linux-based Android kernel. The Android kernel may include a display driver <NUM>, a camera driver <NUM>, a communication driver <NUM>, and a shared memory <NUM>. For example, the communication driver <NUM> may include a Wi-Fi driver and a Bluetooth driver.

In an embodiment, the kernel <NUM> may include a Direct Rendering Manager (DRM) as the display driver <NUM>. The display driver <NUM> may be a kernel driver for controlling graphics hardware with a subsystem of the Linux-based kernel because the display driver <NUM> enables graphics processing unit (GPU) access. Further, the display driver <NUM> may control display control and GPU control together through the DRM.

The kernel <NUM> may initialize the driver for the hardware <NUM> device. In this case, the kernel <NUM> may initialize memory protection, virtual memory modules, and schedule caching. Further, the kernel <NUM> may initialize the operating system. In an embodiment, the kernel <NUM> may execute processes of the vehicle software control device <NUM> to read configuration files describing system services and additional system parameters for the Android-based operating system.

Further, the kernel <NUM> according to the embodiment may simultaneously or independently execute the Android-based first application <NUM> thereon. Accordingly, an Android application (the first application to be described below) may be executed on the vehicle software control device <NUM> according to the embodiment.

Further, in an embodiment, the control signals may be provided to the hardware <NUM> by the first application <NUM> through the kernel <NUM> without virtualization. The first application <NUM> may be displayed on a display of the hardware <NUM>, and a user may access the operating system by performing an input on the display (e.g., a touch on the touch screen). In an embodiment, the user may access the operating system on the kernel <NUM> using the GUI.

Further, in an embodiment, the kernel <NUM> may further include kernel features required for the first connecting unit <NUM> which drives a first operating system. For example, the kernel <NUM> may include a logger, ashmem, LMK, a binder, a namespace, control groups (cgroups), and the like, which are required for Linux Containers (LXC).

The system library <NUM> may be positioned on the kernel <NUM> and may finally provide a request from the first application <NUM> to the kernel <NUM>. As described above, the kernel <NUM> may control the hardware <NUM> by transmitting the request from the first application <NUM> to the hardware <NUM>. Here, the request which is transmitted to the hardware <NUM> by the kernel <NUM> may be the above-described various control signals.

However, the operating system executed on the kernel <NUM> of the vehicle software control device <NUM> may differ from an operating system of the laptop computer or a mobile operating system due to a different environment of the first application <NUM> executed on each system. Accordingly, there may be a limitation that the first application <NUM> executed on the mobile operating system is executed on the vehicle software control device <NUM>.

Referring to <FIG> and <FIG>, the first connecting unit <NUM> of the vehicle software control device <NUM> according to the embodiment includes a first application library <NUM>, a conversion unit <NUM>, a transmission unit <NUM>, and a first calling unit <NUM>.

The first application library <NUM> may include a library necessary for execution of the first application <NUM>. When the first application <NUM> is executed, the necessary library may be called. For example, the first application library <NUM> may implement common functions such as I/O and string manipulation (e.g., "C library"), graphics library, database library, communication library, and other libraries for the executed first application <NUM>. The first application library <NUM> may provide the called library to the conversion unit <NUM>.

The conversion unit <NUM> may receive the called library and convert the received library so as to interface with the system library <NUM>.

For example, the conversion unit <NUM> may convert the called library on the basis of the system library <NUM> of the vehicle software control device <NUM>. The operating system of the vehicle software control device <NUM> and the operating system in which the first application <NUM> is executable may be Linux-based operating systems.

For example, when the first application <NUM> is executed on Google's Android operating system, Android based on Linux may require modifications to the vehicle software control device <NUM> environment (the system library <NUM>) and the kernel <NUM>. As described above, the vehicle software control device <NUM> may use the Linux-based kernel <NUM>.

As described above, the Linux-based kernel may be designed with the processor <NUM> different from the Android-based kernel, but the Linux-based kernel may be the same as the Android kernel in that the kernel is designed based on Linux. Accordingly, the conversion unit <NUM> may convert the first application <NUM> executed on the Android-based kernel into the system library <NUM> of the vehicle software control device <NUM> such that the first application <NUM> executed on the Android-based kernel acts on the hardware <NUM> including a touch screen, a mobile connection (Global System for Mobile Communications (GSM)/Enhanced Data rates for GSM Evolution (EDGE), code division multiple access (CDMA), Wi-Fi, etc.) module, a battery management module, a GPS module, an accelerometer, and a camera module.

In addition, the library converted by the conversion unit <NUM> may be transmitted to the hardware <NUM> through the system library <NUM> and the kernel <NUM> as a control request. The hardware <NUM> may be controlled in response to the control request.

The kernel <NUM> may receive a control result from the hardware <NUM> and transmit the control result to the system library <NUM>. A library for the control result transmitted to the system library <NUM> may be transmitted to the transmission unit <NUM>. The transmission unit <NUM> may transmit the library for the control result to the conversion unit <NUM>, and the conversion unit <NUM> may match the transmitted library for the control result with the first application library <NUM> and convert the library. That is, the library for the control result may be converted so as to match the interface of the first application library <NUM>, and the control result for the hardware <NUM> may be transmitted to the first application <NUM> and provided to the user on the display.

The transmission unit <NUM> may transmit the converted library to the system library <NUM>. Further, the transmission unit <NUM> may receive the library for the control result as described above.

Therefore, the vehicle software control device <NUM> according to the embodiment may execute the first application <NUM> without a virtual machine between the operating system of the first application <NUM> and the operating system of the vehicle software control device <NUM> in which a difference is present in the kernel <NUM> and may control the hardware <NUM> of the vehicle software control device <NUM>.

Accordingly, the vehicle software control device <NUM> according to the embodiment may include the first connecting unit <NUM> which is executed on the kernel <NUM> and the system library <NUM> with a second operating system different from the first operating system even when the kernel <NUM> is executed by the first operating system (Linux). Accordingly, the vehicle software control device <NUM> according to the embodiment may be deployed on Linux systems without generating multiple partitions and may provide improved flexibility and stability on Android devices. In addition, the vehicle software control device <NUM> according to the embodiment may include the second connecting unit <NUM> and the second application <NUM>, which are executed on the first operating system (Linux) which will be described below and may perform various operations by default for the second connecting unit <NUM> and the second application <NUM>. Accordingly, since the vehicle software control device <NUM> according to the embodiment uses the first operating system, which is Linux, a booting speed thereof may be improved as compared with a system which uses the second operating system, and utilization as an open source may also be significantly increased.

Further, the vehicle software control device <NUM> according to the embodiment is not driven on the system library <NUM> by a virtual machine or a hypervisor through the first connecting unit <NUM>. The virtual machine or the hypervisor may be directly driven on the hardware <NUM> and may be executed through the individual kernel <NUM> of the operating system. For example, since the hypervisor or the virtual machine effectively generates multiple virtual computers in one device, each operating system may have a separate virtual computer. Therefore, multiple operating systems which are executed on one device through the hypervisor and the virtual machine may be executed on a guest operating system rather than the kernel <NUM> of the vehicle software control device <NUM>. Therefore, system overhead may be added for each operating system because the operating system is executed by virtualization. Further, since a CPU and other computing resources have to be allocated to the hypervisor, there is a problem in that each operating system cannot effectively schedule processes and tasks. Accordingly, the vehicle software control device <NUM> according to the embodiment may effectively perform the processes and tasks with system performance as it is without virtualization of the hardware <NUM> resources, and the processes and tasks may be executed on the kernel <NUM> of the vehicle software control device <NUM>.

The first calling unit <NUM> may call the system library <NUM> rather than the kernel <NUM>. In an embodiment, the first calling unit <NUM> may be positioned in the system library that causes the second operating system to be implemented and operated. The first calling unit <NUM> may first call the system library <NUM> rather than the kernel <NUM>. In other words, the first calling unit <NUM> that causes the second operating system to be implemented and operated may call the system library <NUM> that causes the first operating system different from the second operating system to be implemented and operated. The second calling unit <NUM> in the system library <NUM> may call the kernel <NUM>. Therefore, the kernel <NUM> may use the called driver (e.g., the hardware driver) to perform a call for accessing a corresponding device in the hardware <NUM> through an application program interface (API) such as the hardware driver and the like. Here, the corresponding device in the hardware <NUM> may be the same as the device in the hardware driver, which is called through the kernel <NUM>.

In an embodiment, the first calling unit <NUM> may call the system library <NUM> rather than the kernel <NUM> in the system library of the Android operating system and then the system library <NUM> may call the kernel <NUM> so that device access may be allowed. In such a configuration, the vehicle software control device <NUM> according to the embodiment may easily access the hardware changed only by modification of the system library <NUM> without changing the system library on the second operating system in the first connecting unit <NUM> even when the hardware <NUM> is changed. Further, the vehicle software control device <NUM> according to the embodiment may access each hardware component even when various chip manufacturers provide a hardware dependent library only in a predetermined operating system version, and thus improved compatibility may be provided. That is, the vehicle software control device <NUM> may be independent of a type or version of the operating system.

More specifically, in a system architecture in which a host operating system (here, which corresponds to the first operating system) is the same as a sub operating system (here, which corresponds to the second operating system and is present on, for example, a container), a system library of the host operating system may be the same as a system library of the sub operating system so that device access may be made as if the kernel <NUM> is shared. However, in the embodiment, since a system architecture in which a host operating system and a sub operating system have different operating systems (the first operating system and the second operating system, respectively) is provided, a system library (which corresponds to the system library <NUM>) of the host operating system may be different from a system library (which corresponds to the system library in the connecting unit) of the sub operating system. In this case, the first calling unit <NUM> in the system library of the sub operating system may call the system library of the host operating system so that access to the hardware may be performed.

When the first calling unit <NUM> transmits the control signal to the kernel <NUM>, the first calling unit <NUM> may call the system library <NUM> before opening various device drivers (the display driver, the camera driver, and the like) in the kernel <NUM> described above. That is, a call signal may be primarily provided to the system library <NUM> by a call, and the second calling unit <NUM> in the system library <NUM> may re-open the device driver in the kernel <NUM> in response to the call signal. That is, the second calling unit <NUM> may open the device driver in the kernel <NUM> having the same function as that of the open device driver. The second calling unit <NUM> may perform the call by the system library in the second connecting unit <NUM> as well as the call by the first calling unit <NUM>.

In the above-described manner, the kernel <NUM> may receive control information from the first connecting unit <NUM>. In addition, even when the kernel <NUM> receives an event input through the hardware, the order is reversed and the rest is performed in the same manner.

Further, the first calling unit <NUM> and the second calling unit <NUM> may include a hardware abstraction layer (HAL). Accordingly, the first calling unit <NUM> and the second calling unit <NUM> may be composed of a plurality of library modules.

Referring to <FIG>, booting may be performed in the kernel <NUM> of the embodiment. That is, kernel information may be loaded into a memory, and system control authority may be transferred to the kernel. Further, the kernel <NUM> may initiate an operation of the first operating system (e.g., Linux) and check the hardware <NUM>. A first process may be executed by the kernel. In this case, the first connecting unit <NUM> according to the invention adds a path of the system file in the kernel <NUM> described above to a path of the system file in the second operating system. That is, the system file of the first connecting unit <NUM> includes a path of the system file for the first operating system.

According to the invention, a system file L1 in the first connecting unit <NUM> includes the same information as that of the system file in the kernel <NUM>. A library file L1 in the first connecting unit <NUM> includes a library file L1a which is applicable to the second operating system and a library file L1b which is the same as a library file L2 in the kernel <NUM>.

Referring again to <FIG>, the second connecting unit <NUM> may be executed based on the first operating system. In an embodiment, the second connecting unit <NUM> may be AGL. The second connecting unit <NUM> may include an AGL service and an AGL framework. Further, the AGL service may include various services, such as a network for controlling network functions, graphics for controlling display-related functions, a resource manager for controlling resource-related functions, an audio for controlling audio-related functions, telematics for controlling communication-related functions, a smartphone link for controlling connection functions with a smartphone, and the like.

Further, the AGL framework may include managers, such as an application manager for managing a life cycle of an application (second application which will be described below) executed on the AGL, a window manager for managing a screen display layout of the second application on the AGL, an input manager for managing a portion received from the second application, a policy manager for managing information and resources of the second applications, a user manager for managing multi-user functions, a sound manager for managing audio-related functions, and the like.

The second application <NUM> may include various applications executed on the second connecting unit <NUM>. For example, the second application <NUM> may include a media player, which is a media playback application, a web browser, and an Android container monitoring server and agent, which is a container management application. The second application <NUM> may be executed on the first operating system, for example, Linux, as described above.

<FIG> is a flowchart of a first application control method of the vehicle software control device according to the embodiment.

Referring to <FIG>, the first application control method of the vehicle software control device according to the embodiment may include executing the first application (S310), generating, by the first connecting unit, a signal on the basis of the system library (S320), transmitting the signal to the system library and the kernel (S330), controlling, by the kernel, the hardware in response to the signal (S340), and transmitting a control result to the first application (S350).

As described above, the first application may be executed by a user. For example, the first application may be a mobile app. The first application may be executed on an Android operating system.

The first connecting unit may generate a signal after the execution of the first application. The signal may be a signal for controlling a device of the hardware. Specifically, a corresponding request may be transmitted to the first connecting unit due to the execution of the first application. The first connecting unit may call the first application library in response to a request of the first application as described above. Therefore, the first application library may provide a called library including a character string, etc. to the conversion unit.

The conversion unit may receive the called library to convert the received library so as to interface with the system library of the vehicle software control device, and the transmission unit may transmit the converted library to the system library. The first calling unit may call the second calling unit so as to open a corresponding hardware driver with the system library and finally provide an interface to easily manipulate each hardware component in the kernel.

The converted library may be converted into a signal suitable for the operating system of the vehicle software control device in the system library and transmitted to the kernel. The kernel may control the hardware in response to the signal.

The kernel may receive the control result from the hardware and transmit the control result to the system library. A library for the control result transmitted to the system library may be transmitted to the transmission unit. The transmission unit may transmit the library for the control result to the conversion unit, and the conversion unit may match the transmitted library for the control result with the first application library and convert the library.

<FIG> is a view showing a vehicle including the vehicle software control device according to the embodiment.

Referring to <FIG>, the vehicle may include vehicle components <NUM>, a processing module <NUM>, and a bus <NUM>.

The vehicle component <NUM> may be an exemplary configuration connected to the bus <NUM>.

For example, the vehicle <NUM> includes wheels, a power source, a steering wheel, a display panel (e.g., an instrument panel), and a passenger seat system.

The vehicle components <NUM> of the vehicle <NUM> may include a wireless signal receiver and a satellite positioning system receiver (e.g., a GPS), a Global Navigation Satellite System (GLONASS, Russia), a Galileo Positioning System (EU), a Compass navigation system (China), and a Regional Navigational Satellite System (India).

Further, the vehicle <NUM> includes a plurality of control units and sensors as the vehicle components <NUM>. For example, the control units and the sensors may sense vehicle speed, acceleration, deceleration, wheel rotation, wheel speed (e.g., revolutions per minute of the vehicle wheel), wheel slip, and the like.

Further, the control units and the sensors may include a power controller and an energy output sensor. The control units and the sensors may control balance of fuel (e.g., Gasoline, natural gas or other mixture) or measure one or more of energy input and output (e.g., a voltage, a current, fuel consumption, and torque).

Further, the vehicle components <NUM> may include a transmission control unit. The transmission control unit may control a current state of a transmission (e.g., gear selection or setting).

The control units and the sensors may include an airbag system for safety. The airbag system may include an airbag control unit and a collision sensor. When collision is detected by the collision sensor, detected data may be transmitted to an airbag release control unit, and the airbag release control unit may determine whether the airbag is inflated based on the data reception. In addition, safety components may include a seat belt control device, a headlight control device, a camera, or other image sensor, but the present disclosure is not limited thereto.

Further, the vehicle components <NUM> may provide entertainment options such as music or video for passengers.

The processing module <NUM> may monitor or control the sensors and the control units described above. (e.g., an engine, a transmission, a towing and safety control module, a parallel parking assistance system, an occupant protection system, a power steering assistance device, a self-diagnostic device, an event data recording device, a steer by telematics module, a navigation, a multimedia system, an audio system, a rear seat entertainment system, a vehicle and other vehicle software control device, a vehicle and a vehicle interaction module, a vehicle interaction module, a game console, an adaptive cruise control module, an adaptive headlight, a collision warning module, a blind spot intelligent sensor, a parking/stationary module, a tire pressure monitoring module, a dashboard, lighting, seats, a climate control module, a voice recognition module, a remote control module, a security alarm system, and a wiper/window control module).

As described above, the processing module <NUM> may be positioned at any position of the vehicle. Further, a plurality of processing modules <NUM> may be disposed at any position even when the same sensing function is performed. For example, even when the processing module <NUM> for controlling collision with a rear of the vehicle <NUM> is damaged, the processing modules <NUM> disposed at other positions of the vehicle may not be damaged.

Applications which are accessible through the processing modules <NUM> may include, for example, a dial, gauges (e.g., a cyclometer, a speedometer, an oil pressure, an engine temperature, indoor/outdoor temperature, a trip computer, a maintenance tire pressure, vehicle/part performance monitoring, and other vehicle-related detection information), an application associated with a handicap and accessibility graphic user interface (e.g., large fonts, controls, text-to-speech conversion, text interface, voice command interface, etc.), an e-mail client, a web browser, a communication application (e.g., an e-mail application, a text messaging application, a telephony application, etc.), games (e.g., a solo or multi-party game, access to other multimedia files, specifically audio and/or video files, watching, or listening), a satellite positioning system receiver application (e.g., location tracking, vehicle tracking, map applications, medical information applications, and emergency services applications), a noise suppression application, a news-related application, a biometric first application (e.g., an iris recognition system for user identification, etc.), and a travel application.

The bus <NUM> may be connected to each of the processing modules <NUM>. The bus <NUM> may include a standardized communication network. The standardized communication network may include Ethernet, Wi-Fi, Universal Serial Bus (USB), Inter-Integrated Circuit (I<NUM>C), Recommended Standard <NUM> (RS232), RS485, and FireWire. For example, the bus <NUM> may include and support buses <NUM> with a standardized communication network such as a campus area network (CAN).

The vehicle components <NUM>, the processing module <NUM>, and the bus <NUM> of the vehicle <NUM> which are described above may be included in the hardware of the vehicle software control device described above. Therefore, the vehicle components <NUM>, the processing module <NUM>, and the bus <NUM> of the vehicle <NUM> may operate in response to a request by the first application.

<FIG> is a diagram for describing an infotainment vehicle software control device.

Referring to <FIG>, the vehicle infotainment system may include a plurality of I/O systems 2100a, 2100b, and 2100n and may receive user input from a media control unit <NUM>, a display control unit <NUM>, and an audio control unit <NUM> around the user and provide an output corresponding to the input using the plurality of I/O systems 2100a, 2100b, and 2100n.

For example, when the user receives an input for voice control through the plurality of I/O systems 2100a, 2100b, and 2100n by executing the first application, a voice output corresponding to the input may be provided to the user. Further, the voice output through the application may be streamed to a speaker among the vehicle components or transmitted to an interface selected by the user.

Claim 1:
A vehicle software control device comprising:
hardware (<NUM>);
a kernel (<NUM>) connected to the hardware (<NUM>) and configured to execute a first operating system;
a system library (<NUM>) connected to the kernel (<NUM>);
a first connecting unit (<NUM>) configured to connect a library for a second operating system different from the first operating system to the system library (<NUM>); and
a first application (<NUM>) executed on the second operating system, wherein a library file (L1) of the first connecting unit (<NUM>) includes the same information as that of the system file in the kernel (<NUM>), wherein the library file (L1) of the first connecting unit (<NUM>) includes a library file (L1a) applicable to the second operating system and a library file (L1b) which is the same as a library file (L2) in the kernel (<NUM>),
wherein the first connecting unit (<NUM>) is adapted to add a path of the system file in the kernel (<NUM>) to a path of a system file in the second operating system,
wherein a system file of the first connecting unit (<NUM>) includes a path of a system file for the first operating system, wherein the first connecting unit (<NUM>) includes a first calling unit which opens a driver in the system library (<NUM>),
wherein the system library (<NUM>) includes a second calling unit which opens a device driver in the kernel (<NUM>) which performs the same function as that of the driver in the system library (<NUM>),
further comprising:
a first application library (<NUM>) including a library for executing the first application (<NUM>);
a conversion unit configured to convert the library for executing the first application (<NUM>) so as to interface with the library of the system library (<NUM>); and
a transmission unit (<NUM>) configured to transmit the converted library to the system library.