Control method and device for automotive on-board service, and automobile

Abstract

This application relates to the field of automotive technology and discloses a control method for automotive applications-free services. The method includes: parsing the raw protocol data of devices connected to the vehicle to obtain a structured device capability description file; uploading the device capability description file and the vehicle's context information to a cloud service platform, and obtaining a service card template generated by the cloud service platform based on the device capability description file and context information; instantiating and rendering the service card template to generate an interactive dynamic service card view; and generating device control commands for the connected devices in response to user interactions in the dynamic service card view, thereby controlling the connected devices to provide services. This method significantly improves the scene adaptability of the in-vehicle service interface and enhances the user experience. This application also discloses a control device and a vehicle for automotive applications-free services.

Description

Technical Field

[0001] This application relates to the field of automotive technology, such as a control method and device for automotive applications without application services, and an automotive. Background Technology

[0002] With the rapid development of intelligent connected vehicles and Internet of Things (IoT) technologies, the prevalence of in-vehicle infotainment systems (IVI) and various IoT devices in the vehicle environment is increasing. Currently, if users want to use the functions provided by extended access devices such as in-vehicle refrigerators, microphones, audio systems, and dashcams, they usually need to download and install corresponding standalone applications (Apps) on the vehicle's infotainment system or mobile device beforehand. This approach is not only cumbersome but also forces users to switch between different applications, resulting in a fragmented service experience.

[0003] In related technologies, a pre-configured instruction format table is used to achieve unified access for devices using vendor-defined protocols. This allows users to operate multiple devices through a unified interface or service entry point on the vehicle's infotainment system, simplifying the operation process and alleviating fragmented service experiences. The core of this solution lies in pre-parsed the communication protocols of different devices and standardize their instruction formats, storing this as a static "instruction mapping table" in the vehicle's infotainment system. When a compatible device connects, by querying this mapping table, the unified operation instructions can be converted into specific protocol instructions that the device can recognize, thereby enabling service control of the connected device.

[0004] In the process of implementing the embodiments of this disclosure, at least the following problems were found in the related art: Manually parsing and configuring each new access device or communication protocol relies heavily on the prior knowledge and manual input of developers or users. When faced with real-world application scenarios involving rapid iteration of device models and diverse and dynamically changing protocols, it is difficult to achieve flexible, efficient, and automated device access and service provision, resulting in weak scenario adaptability.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0007] This disclosure provides a control method and apparatus for automotive applications without application-based services, as well as an automotive vehicle, to improve the scenario adaptability of the in-vehicle service interface.

[0008] In some embodiments, the control method for automotive application-free services includes: parsing the raw protocol data of the devices connected to the vehicle to obtain a structured device capability description file of the connected device; uploading the device capability description file and the vehicle's context information to a cloud service platform, and obtaining a service card template generated by the cloud service platform based on the device capability description file and the context information; instantiating and rendering the service card template to generate an interactive dynamic service card view; and generating device control instructions for the connected device in response to user interaction in the dynamic service card view, so as to control the connected device to provide services.

[0009] Optionally, the original protocol data of the devices connected to the vehicle is parsed to obtain a structured device capability description file, including: parsing the original protocol data to identify key metadata of the access devices; wherein, the key metadata includes one or more of the following: type, brand, function instruction set, data read / write format, status variables, and encoding rules of the access devices; and converting the key metadata into a structured description file in a unified format as the device capability description file.

[0010] Optionally, the device capability description file and the vehicle's context information are uploaded to the cloud service platform, and a service card template generated by the cloud service platform based on the device capability description file and the context information is obtained. This includes: collecting the vehicle's context information; wherein the context information includes vehicle status, environmental data, and user information; uploading the device capability description file and the context information to the cloud service platform so that the cloud service platform can generate a service card template adapted to the current scenario based on the device capability description file and the context information; wherein the service card template defines the interactive interface, data logic, and call interface in a structured language.

[0011] Optionally, based on the device capability description file and context information, a service card template adapted to the current scenario is generated, including: mapping the device functions defined in the device capability description file to service atoms that can be called, and forming a scenario vector representing the current scenario based on the context information; determining the target service mode based on the scenario vector, and selecting and arranging interface components from the component library according to the target service mode to form an interface layout; binding the interface layout to the service atoms to generate a service card template.

[0012] Optionally, instantiation and rendering are performed based on the service card template to generate an interactive dynamic service card view, including: obtaining the current vehicle data according to the interface structure and data binding relationship defined in the service card template; binding the current vehicle data with the service card template and completing instantiation, and rendering and generating the dynamic service card view.

[0013] Optionally, in response to user interaction with the dynamic service card view, device control commands for the access device are generated, including: capturing user interaction events with the dynamic service card view; and calling cloud interfaces to process the interaction events and generate device control commands according to the logic defined in the service card template.

[0014] Optionally, the control method for automotive application-free services further includes: creating a first service instance when the access device is identified; wherein the first service instance includes a first service card template and a first dynamic service card view; deleting the first service instance and releasing the memory resources occupied by the first service instance when the first service scenario of the access device fails; wherein the failure of the first service scenario includes the access device disconnecting or the user actively closing the first service card view.

[0015] Optionally, the control method for automotive application-free services further includes: creating a second service instance when the access device is first identified; wherein the second service instance includes a second service card template and a second dynamic service card view; during the existence of the second service instance, it supports multiple invocations and uses by the user; in the event that the second service scenario of the access device fails, the second service instance is deleted and the memory resources occupied by the second service instance are released; wherein the failure of the second service scenario includes the access device being removed or the user actively uninstalling the service card view.

[0016] In some embodiments, the control device for vehicle-to-everything (V2X) services includes a processor and a memory storing program instructions, the processor being configured to execute the aforementioned control method for V2X services when the program instructions are executed.

[0017] In some embodiments, the vehicle includes: a vehicle body; and the aforementioned control device for vehicle-to-everything (V2X) services, disposed on the vehicle body.

[0018] The control method and apparatus for automotive applications-free services, and the automotive provided in this disclosure, can achieve the following technical effects: First, the vehicle-side parses the raw protocol data of the connected devices to obtain a structured device capability description file. It then uploads this file, along with the vehicle's context information, to the cloud service platform. Next, the cloud service platform generates a service card template based on the device capability description file and context information. Then, the vehicle-side instantiates and renders this template, generating an interactive, dynamic service card view. Responding to user interactions within this view, the platform generates device control commands for the connected devices, which then provide services according to these commands. This process, generating service card templates based on device capability description files and context information, eliminates reliance on pre-defined static logic. Instead, it enables real-time, intelligent reorganization of interface elements and functional adaptation based on the current connected devices and environment. The vehicle-side performs real-time data binding and rendering based on the service card template, creating a dynamic service card view that evolves with changes in connected devices, scenarios, and user states. This significantly improves the adaptability of the in-vehicle service interface and enhances the user experience.

[0019] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0020] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic flowchart of a control method for automotive application-free services provided in an embodiment of this disclosure; Figure 2 This is a flowchart illustrating another control method for automotive application-free services provided in this embodiment of the disclosure; Figure 3 This is a flowchart illustrating another control method for automotive application-free services provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the hardware architecture of a control method for automotive applications-free services provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of a control device for automotive application-free services provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of a car provided in an embodiment of this disclosure. Detailed Implementation

[0021] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0022] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0023] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0024] Unless otherwise stated, the term "multiple" means two or more. In embodiments of this disclosure, the character " / " indicates that the preceding and following objects are in an "OR" relationship. For example, A / B means: A or B. The term "and / or" describes an association relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B. The term "correspondence" can refer to an association or binding relationship; A corresponding to B means that there is an association or binding relationship between A and B.

[0025] This disclosure provides a hardware architecture diagram of a control method for automotive applications without application-based services, based on an embodiment. Figure 4 As shown, the hardware architecture includes a cloud service platform, vehicle-mounted devices, and access devices that are interconnected, wherein: A cloud service platform refers to a software system deployed on a remote server that possesses artificial intelligence (AI) reasoning and computing capabilities. The cloud service platform receives structured device capability description files and multi-dimensional scenario information from the vehicle, and through intelligent analysis, decision-making, and combination, dynamically generates an executable interactive interface description (i.e., a service card template) that is highly matched to the current context, and then sends it to the vehicle.

[0026] The vehicle-side refers to the computing and control hub deployed inside a vehicle, typically an in-vehicle infotainment system (IVI) or a smart gateway. The vehicle-side can perform the following functions: real-time parsing of the original protocols of access devices; collection of vehicle and contextual information; receiving and rendering service card templates issued by the cloud service platform; processing user interaction events based on dynamic service card views; and converting device control commands into protocols recognizable by the access devices and issuing them to the corresponding access devices.

[0027] Access devices refer to various Internet of Things (IoT) devices or in-vehicle function extension devices (such as smart refrigerators, microphones, ambient lights, etc.) that establish a connection with the vehicle via wired (such as USB, CAN) or wireless (such as Bluetooth, Wi-Fi) methods. Access devices are responsible for receiving and executing standardized control commands from the vehicle to implement specific functional services (such as cooling, recording, dimming), and feeding back their own status data to the vehicle.

[0028] The vehicle-mounted terminal acts as a bridge connecting the cloud service platform and access devices. It senses raw data from access devices and uploads it to the cloud service platform, controlling the access devices to provide services. The cloud service platform generates service card templates and distributes them to the vehicle-mounted terminal. The cloud service platform and access devices do not communicate directly; instead, they are dynamically bound through the vehicle-mounted terminal as middleware. This allows any access device that conforms to the protocol to obtain a dynamic interactive interface provided by the cloud service platform, matching its capabilities, through the vehicle-mounted terminal as an intermediary. Through clear role definitions and a tight collaboration mechanism, the cloud service platform, vehicle-mounted terminal, and access devices jointly realize a next-generation in-vehicle service paradigm that eliminates the need for pre-installed applications and dynamically generates services based on the scenario.

[0029] Combination Figure 1 As shown in the embodiments of this disclosure, a control method for automotive applications without application-based services is provided, including the following steps: S101, parse the original protocol data of the devices accessed by the vehicle to obtain a structured device capability description file of the access devices.

[0030] Optionally, the original protocol data of the devices connected to the vehicle is parsed to obtain a structured device capability description file, including: parsing the original protocol data to identify key metadata of the access devices; wherein, the key metadata includes one or more of the following: type, brand, function instruction set, data read / write format, status variables, and encoding rules of the access devices; and converting the key metadata into a structured description file in a unified format as the device capability description file.

[0031] In some possible implementations, the raw protocol data is parsed to identify key metadata of the access device, including: using an AI model to capture and identify the raw protocol data to determine the protocol family; and extracting key metadata of predefined categories from the protocol family according to preset structural rules.

[0032] Here, a protocol family refers to a set of interrelated, hierarchical communication rules and data format standards that define how devices establish connections, package data, address each other, ensure transmission reliability, and define the specific meaning of the data. Once a protocol family is determined, the AI ​​model invokes the specific parsing rules designed for that family.

[0033] For example, the original protocol data is a manufacturer-specific data segment in a BLE broadcast packet or a data field in a CAN message. It is determined that its protocol family is a proprietary BLE protocol for a specific manufacturer. The extracted key metadata is "Device type: Refrigerator", "Brand ID: 0x0A", "Function instruction set: {0x01: 'Set temperature', 0x02: 'Query status'}", and "Encoding rule for status variable 'Current temperature': 2 bytes, signed integer, unit 0.1°C".

[0034] In practical applications, the vehicle-mounted system incorporates a pre-trained and fine-tuned dedicated AI model. This model performs real-time decoding and semantic understanding of raw binary or byte stream protocol data to obtain key metadata for predefined categories. The extracted key metadata is then assembled into a structured description file (e.g., JSON or XML format) according to a pre-designed unified data schema, serving as the device capability description file.

[0035] By using a local AI model, the system achieves automated, real-time parsing and standardized description of heterogeneous device protocols. It transforms the chaotic and proprietary raw data stream into device capability description files that the cloud service platform can understand. This fundamentally eliminates the arduous work of manually reverse engineering and configuring protocols for each new device or protocol. It provides an accurate and structured input foundation for the subsequent intelligent generation of cloud service platforms and dynamic rendering on the vehicle side. This is a key prerequisite and core technology support for the automation and scenario adaptation of the entire applicationless service chain.

[0036] S102, upload the device capability description file and the vehicle's context information to the cloud service platform, and obtain the service card template generated by the cloud service platform based on the device capability description file and the context information.

[0037] Optionally, the device capability description file and the vehicle's context information are uploaded to the cloud service platform, and a service card template generated by the cloud service platform based on the device capability description file and the context information is obtained. This includes: collecting the vehicle's context information; wherein the context information includes vehicle status, environmental data, and user information; uploading the device capability description file and the context information to the cloud service platform so that the cloud service platform can generate a service card template adapted to the current scenario based on the device capability description file and the context information; wherein the service card template defines the interactive interface, data logic, and call interface in a structured language.

[0038] Vehicle status refers to a set of internal parameters reflecting the real-time operating status and configuration of the vehicle. Vehicle status data originates from the vehicle's internal network bus (such as CAN, LIN, Ethernet) and onboard controllers. Vehicle status includes driving speed, acceleration, gear position, ignition status, door / window opening / closing status, battery charge, fuel level, driving mode (such as Sport, Eco), and one or more system fault codes. Vehicle status is primarily used to determine the safety boundaries and availability of service interactions; for example, disabling complex touch input or providing only a voice interaction interface during driving.

[0039] Environmental data refers to the set of objectively perceived parameters of the physical environment in which a vehicle is located. Environmental data originates from onboard sensors, geolocation services, and external data interfaces. It includes one or more of the following: temperature inside and outside the vehicle, humidity, ambient light intensity, air quality index (e.g., PM2.5), real-time geolocation, weather conditions (e.g., sunny, rainy, snowy), time (date, hour), and ambient noise levels. Environmental data is used to drive contextualized service adaptation; for example, when high temperatures are detected inside the vehicle, the system automatically optimizes service recommendations for the air conditioning or refrigerator.

[0040] User information refers to a set of data related to the identity, status, and preferences of the current user in the vehicle. It is obtained through the in-cabin perception system and user account system, while adhering to privacy and security regulations. User data includes one or more of the following: user gender, user age, passenger role and distribution (e.g., driver, front passenger), user status (e.g., tired, happy), and service preferences (e.g., favorite music genres, frequently used temperature settings). User information aims to make the generated service interface more tailored to individual needs and real-time status, providing a personalized interactive experience.

[0041] Service card templates are digital blueprints written in a structured, declarative language, used to dynamically define the complete presentation and behavioral logic of an in-vehicle service. Service card templates are the final output of cloud-based intelligent decision-making and the execution basis for the vehicle-side rendering engine. Essentially, a service card template is a data file (typically in JSON, XML, or a domain-specific language DSL) that precisely defines the following elements: User Interface (UI): component type, attributes, style, and layout; Data Binding: the mapping relationship between UI components and device capability data points or cloud data interfaces; Event Logic: the local or cloud processing flow triggered by user actions (such as clicks or voice commands); Call Interfaces: the external APIs or cloud function addresses required for service operation. Service card templates are the core carrier for achieving application-free service, enabling services to operate independently of pre-installed apps, achieving on-demand generation, dynamic rendering, and contextualized interaction.

[0042] In some possible implementations, a service card template adapted to the current scenario is generated based on the device capability description file and context information. This includes: mapping the device functions defined in the device capability description file to service atoms that can be invoked, and forming a scenario vector representing the current scenario based on the context information; determining the target service mode based on the scenario vector, and selecting and arranging interface components from the component library according to the target service mode to form an interface layout; and binding the interface layout to the service atoms to generate the service card template.

[0043] A service atom is a standardized abstract description of an independently invoked device function or cloud capability, containing information such as atom ID, input parameters, output results, and invocation method (e.g., local command or cloud API). Upon receiving the device capability description file, the engine instantiates each specific function (e.g., set_temperature) into a callable service atom through pattern matching (e.g., function name, opcode mapping). For example, the refrigerator's "set temperature" function is mapped to a service atom instance named Atomic_CoolCar_Fridge_SetTemp, with invocation parameters {"value": int16}.

[0044] The process involves generating a scene vector representing the current scene based on contextual information. This includes: using a lightweight model to normalize, quantize, and weightedly fuse multi-source heterogeneous information from the contextual information to generate a fixed-dimensional numerical vector; and using the data vector as the scene vector. For example, vehicle speed > 60km / h is quantized as [speed_level: 2], time = night is quantized as [time_period: 3], and user role = driver is quantized as [user_role: 1], and then combined into a scene vector [2,3, 1, ...].

[0045] The service mode strategy library defines the optimal service objectives (such as "Safe and Simple", "Information Immersion", and "Leisure and Entertainment") and interaction constraints (such as "Disable Complex Input" and "Prioritize Voice") corresponding to different scenario vectors. Scenario vectors are matched against the preset service mode strategy library. After a target service mode is matched, the UI synthesizer selects interface components from the visual component library according to the requirements of the target service mode (e.g., large buttons, voice buttons, and concise information text components for "Safe and Simple" mode; media cards and gallery view components for "Leisure and Entertainment" mode). The layout engine automatically arranges the selected components according to the layout template in the target mode (e.g., a vertical single-column card layout for driving mode and a multi-grid layout for parking mode) to generate the final interface layout.

[0046] The UI compositor logically binds each interactive component in the UI layout to the service atom instantiated in the previous step. For example, it binds the onClick event of the "Temperature+" button in the UI layout to the Atomic_CoolCar_Fridge_SetTemp service atom, passing in the parameter increment. Simultaneously, it data-binds the text component displaying the "Current Temperature" to the subscription channel of the current_temp state in the device capabilities. Finally, the engine compiles or serializes this complete definition, including the UI structure, data binding relationships, event logic, and atomic call paths, into a structured service card template file (such as JSON format).

[0047] The following is a specific example to further illustrate the process of generating service card template files: In a scenario where a dashcam is connected to a nighttime highway, functions such as "emergency recording lock" and "retrieve 30 seconds of previous recording" in the device capability description file are mapped to corresponding service atoms. Contextual information such as "vehicle speed = 110km / h, time = night, light = dark, road type = highway, user role = driver" is quantized into a scene vector [speed level: high, time: night, ambient light: low, road: highway, role: driver]. The policy matcher matches the "nighttime safe driving" target service mode based on this scene vector. The UI compositor then selects from the component library: a large, high-contrast real-time video stream component (placed at the top), a prominent red emergency lock button (placed in an easily accessible location on the screen), and a simplified settings entry. The "emergency lock button" is bound to the "emergency recording lock" service atom. The video stream component is bound to the dashcam's real-time stream address, generating a JSON template that defines this specific layout and interaction logic.

[0048] By abstracting device functions into programmable service atoms and quantifying complex environments into computable scenario vectors, and using these to drive target service mode decisions and dynamic synthesis of interface components, the generation of service card templates is fully automated and highly intelligent. This allows the cloud to break free from its dependence on fixed template libraries and, based on the two core inputs of "what capabilities it currently possesses" and "what its current situation is," reason and combine the optimal interaction solutions in real time. This elevates the granularity of service interface adaptation from "device-level" to "scenario-level," greatly enhancing the system's flexibility and the accuracy of user experience.

[0049] S103 instantiates and renders based on the service card template, generating an interactive dynamic service card view.

[0050] Optionally, instantiation and rendering are performed based on the service card template to generate an interactive dynamic service card view, including: obtaining the current vehicle data according to the interface structure and data binding relationship defined in the service card template; binding the current vehicle data with the service card template and completing instantiation, and rendering and generating the dynamic service card view.

[0051] In some possible implementations, the current vehicle data is obtained based on the interface structure and data binding relationships defined in the service card template. This includes: constructing an abstract view tree corresponding to the service card template; where component nodes in the abstract view tree contain component types (such as Button, TextView), basic styles, and data binding expressions (such as {{current_temperature}} or bind:state.fridge.temp); and obtaining the current vehicle data based on the data binding expressions in the abstract view tree. For example, if there is a TextView node in the abstract view tree with the data binding expression {{device.air_purifier.pm25}}, then the PM25 value of the currently connected air_purifier device (i.e., the current vehicle data) is obtained.

[0052] In some possible implementations, the current vehicle data is bound to the service card template and instantiated, and a dynamic service card view is rendered. This includes: injecting the obtained current vehicle data (initial or updated value) into the data binding expression corresponding to the abstract view tree to complete the association between the data and the view; converting the data-filled abstract view tree into a native UI component instance that can be recognized by the vehicle operating system (such as QNX or Android Automotive) to obtain the dynamic service card view and display the dynamic service card view on the screen.

[0053] The following is a specific example to further illustrate the process of generating dynamic service card views: Render a temperature control card for the in-vehicle refrigerator. The engine parses the service card template and determines that a vertical layout needs to be built, containing a Text component (displaying the title), a TextView component (displaying the current temperature), and a Slider component (adjusting the temperature). The data binding expression for the TextView component is {{states.fridge.currentTemp}}. The engine subscribes to the data point "refrigerator current temperature" from the vehicle's data bus. The data bus reads the temperature (let's say 5°C) from the connected refrigerator device in real time and pushes this value "5" to the rendering engine. The engine fills the value "5" into the TextView component and automatically adds the unit "°C" to form the displayed text "5°C". The current value of the Slider component is also bound to the same data point, so the slider position is automatically initialized to the corresponding 5°C position. The engine creates the corresponding native text view and slider component, sets the text and slider positions, and then hands it over to the vehicle's UI system for final rendering. Users see an interactive interface that displays "Current Temperature: 5°C" in real time with a slider in the corresponding position. When the refrigerator temperature changes, the data bus pushes a new value (such as 3°C), and the engine automatically updates the text of the TextView and the position of the Slider, realizing the dynamic updating of the dynamic service card view.

[0054] By implementing a lightweight rendering engine based on declarative templates and reactive data binding on the vehicle side, the static service blueprints issued by the cloud service platform are efficiently combined with real-time dynamic vehicle data, generating a truly "live" and interactive service interface. This achieves extreme lightweight and dynamic service presentation. The vehicle side does not need to pre-install business logic code, only general template parsing and rendering capabilities. The service view can respond to any changes in vehicle or device status in milliseconds, ensuring the real-time and accuracy of information display. At the same time, this decoupled design allows the cloud service platform to flexibly update service logic and interface definitions, while the vehicle side can present new services without any modifications, greatly improving the overall maintainability, scalability, and adaptability to changing in-vehicle scenarios of the system.

[0055] S104, in response to the user's interactive operation in the dynamic service card view, generates device control commands for the access device to control the access device to provide services.

[0056] Optionally, in response to user interaction with the dynamic service card view, device control commands for the access device are generated, including: capturing user interaction events with the dynamic service card view; and calling cloud interfaces to process the interaction events and generate device control commands according to the logic defined in the service card template.

[0057] In some possible implementations, user interaction events with the dynamic service card view are captured, including: the vehicle-side event processing engine listens for all predefined interactions (such as touch, voice commands, and physical button mappings) on the dynamic service card view; when an interaction event occurs, it is abstracted into a standard structured event object; wherein the structured event object contains: event type (such as CLICK), source component ID (such as btn_cool_fast), event payload (such as {"value":null}), and necessary context snapshot (such as card_instance_id).

[0058] In practical applications, the engine quickly locates the event handler defined for that component in the service card template based on the component ID of the event source. If the event handler is defined as "local logic" (such as a simple interface switch), it is executed directly by the engine. If the event handler is defined as "cloud processing" (for example, containing a cloud API call address and parameter mapping rules), the engine uses an abstract, structured event object as the request body and calls the cloud API through a secure network channel (such as HTTPS). After receiving the event object, the cloud API executes complex business logic through the cloud's interaction logic processor, including: querying user profiles, analyzing real-time big data (such as recommending the ideal temperature for a refrigerator based on the current location and weather), and calling other cloud services (such as payment and content recommendation). After processing, an action command response is generated, which includes: the target device ID, the native command / opcode to be executed, and the command parameters. After receiving the action command response, the vehicle-side event processing engine will convert the standardized operation command into the original protocol data frame (such as a specific CAN message or Bluetooth BLE write operation) that the target access device can accurately recognize, according to the type and protocol of the target access device. The generated device control command will then be sent to the target access device through the corresponding physical channel (CAN bus, Bluetooth connection, etc.).

[0059] By moving the processing logic of user interaction events (especially those involving complex decision-making, data fusion, and personalized services) to the cloud, a perfect decoupling of business intelligence and terminal control is achieved. This greatly frees up the limited computing resources on the vehicle side, allowing them to focus on highly reliable real-time rendering and device control. Simultaneously, it fully leverages the powerful computing capabilities, massive amounts of data, and intelligent algorithms of the cloud to provide users with deeply personalized and context-aware complex services. This enables simple user interactions (such as a single click) to trigger a series of intelligent decisions and cross-service collaborations, ultimately generating precise device control commands. This upgrades in-vehicle services from "functional remote control" to "scenario-driven intelligence," significantly enhancing the added value, intelligence level, and user experience of the service.

[0060] The control method for automotive application-free services provided in this disclosure firstly involves the vehicle-side parsing the original protocol data of the connected devices to obtain a structured device capability description file. This device capability description file, along with the vehicle's context information, is then uploaded to a cloud service platform. Next, the cloud service platform generates a service card template based on the device capability description file and the context information. Then, the vehicle-side instantiates and renders the service card template, generating an interactive dynamic service card view. Responding to user interactions within the dynamic service card view, the platform generates device control commands for the connected devices, which then provide services according to these commands. This method, generating service card templates based on device capability description files and context information, eliminates reliance on pre-defined static logic. Instead, it enables real-time, intelligent reorganization of interface elements and functional adaptation based on the current connected devices and the surrounding environment. The vehicle-side performs real-time data binding and rendering based on the service card template, forming a dynamic service card view that evolves dynamically with changes in connected devices, scene transitions, and user states. This significantly improves the scene adaptability of the in-vehicle service interface and enhances the user experience.

[0061] In some embodiments, the control method for automotive application-free services further includes: creating a first service instance when an access device is identified; wherein the first service instance includes a first service card template and a first dynamic service card view; deleting the first service instance and releasing the memory resources occupied by the first service instance when a first service scenario of the access device fails; wherein the failure of the first service scenario includes the access device disconnecting or the user actively closing the first service card view.

[0062] Optionally, when an access device is identified, a first service instance is created, including: parsing the protocol of the new access device and generating a device capability description file; if the new access device is marked as an instant service, requesting the corresponding first service card template from the cloud or obtaining it from the local cache, and calling the rendering engine to create a first dynamic service card view corresponding to the first service card template.

[0063] In practical applications, a unique instance ID is assigned to the first service instance, and the {instance ID, device ID, template reference, view reference, data connection handle} is registered in the service instance registry as a complete first service instance record, and begins to occupy computing and memory resources. Upon detecting a disconnection of the access device (e.g., Bluetooth disconnection, USB unplugging) or the user actively closing the first service card view (e.g., the user closes or exits the service card view), a cascading deletion is executed. The cascading deletion includes: closing all data subscriptions and long connections bound to the first service instance; destroying the view instance of the first service instance, triggering the UI system to reclaim graphics resources; and deleting the first service instance record from the registry, releasing all memory data structures occupied by the first service instance.

[0064] In a scenario where a user connects a wireless in-car karaoke microphone for entertainment while traveling: the microphone connects via Bluetooth BLE and is identified as an "instantaneous audio input device"; the service instance manager is triggered, requesting a "karaoke entertainment" service template from the cloud service platform; the cloud service platform returns a service card template containing lyrics view, sound effect buttons, and recording controls; the manager instructs the rendering engine to create the corresponding karaoke interface view in the background; the manager registers an instance: {ID: "Karaoke_001", Device: "Mic_BLE_Addr", View: ref_xxx, DataConn: [audio stream, sound effect control]}. When a user clicks the icon, the view is activated and the user begins singing. When the user finishes singing, the microphone is turned off, the Bluetooth connection is lost, and the underlying system notifies the manager: "Device Mic_BLE_Addr has been disconnected." Upon receiving the notification signal, the manager stops capturing audio streams from the microphone, releases the audio processing buffer, destroys the lyrics and sound effects UI, and completely clears all data from the Karaoke_001 instance from memory. Within seconds, the tens of MB of memory occupied by the service instance (used for audio buffering and UI textures) are completely reclaimed, as if it had never run.

[0065] By implementing a precise and automated real-time service lifecycle management mechanism, the concept of "build as needed and leave when finished" is transformed into a reliable technical practice. By strictly binding the service instance to the connection status of the physical device or the user's explicit interaction intent, it ensures that the service is created and occupies resources only when absolutely necessary. Once the service scenario ends, the system can instantly and automatically reclaim all resources without any residue, achieving "zero idle" and efficient utilization of the vehicle's limited system resources (especially memory).

[0066] In some embodiments, the control method for vehicle-to-everything (V2X) services further includes: creating a second service instance when the access device is first identified; wherein the second service instance includes a second service card template and a second dynamic service card view; supporting multiple invocations and uses by the user during the existence of the second service instance; deleting the second service instance and releasing the memory resources occupied by the second service instance in the event that the second service scenario of the access device fails; wherein the failure of the second service scenario includes the access device being removed or the user actively uninstalling the second service card view.

[0067] Optionally, when an access device is identified, a second service instance is created, including: parsing the protocol of the new access device and generating a device capability description file; if the new access device is marked as a normal service, requesting the corresponding second service card template from the cloud or obtaining it from the local cache, and calling the rendering engine to create a second dynamic service card view corresponding to the second service card template; persistently storing the core metadata of the second service instance (such as instance ID, device ID, template version, last state snapshot, etc.) in the non-volatile storage (such as eMMC) of the vehicle's memory to form a persistent service record.

[0068] In practical applications, users can invoke services through the vehicle's application list, shortcut cards, or voice commands. Upon receiving an invocation request, the manager first checks if an active view instance exists in the vehicle's memory. If not, a rapid recovery process is executed: based on the template information in the persistent service record, it re-requests the second service card template from the cloud or loads it from the local cache, and instructs the rendering engine to re-instantiate the view to obtain the second dynamic service card view. Simultaneously, it attempts to read the latest state from the access device or restore the last saved interface state (such as the previously set refrigerator temperature) to achieve breakpoint continuation. If the access device is detected as removed (e.g., CAN node offline, Bluetooth device timeout and cleanup due to non-reconnection) or the user actively uninstalls the second service card view (e.g., the user uninstalls or deletes the second service card view in system settings), a thorough cleanup is performed. This thorough cleanup includes: terminating all connections and subscriptions; destroying active view instances; deleting the second service instance record from persistent storage; and clearing all related local cache data and user preference settings.

[0069] In a scenario where a home MPV has a built-in in-vehicle compressor refrigerator: Upon vehicle delivery, the refrigerator is identified as a "normal" device by the system as a pre-installed device. The manager creates a "Car Refrigerator" service instance, generates a control interface, and stores the service record (e.g., Service ID: Fridge_Main, Template Version: v1.2, Default Temperature: 4°C) in the vehicle's storage. The user sets the preferred temperature to 2°C, and this preference is also saved. Each time the user gets into the vehicle, they can open the refrigerator control interface with one click through the "Device" list on the central control screen. The manager quickly restores the view and displays the current temperature as 2°C. Even if the vehicle system is upgraded and restarted, the refrigerator's service record still exists. After restarting, the user can still invoke the service through the same entry point, and the interface and settings are restored. If the refrigerator malfunctions and is completely removed for repair, the manager performs a deletion operation. The refrigerator's control interface disappears from the application list, all its storage records and cached data are cleared, and related memory and storage resources are completely released, as if the service had never been installed.

[0070] By designing an independent lifecycle model with persistence and state management capabilities for routine services, a balance is achieved between the continuity of long-term service experience and the long-term health of system resources. While ensuring that core service entities are "created once and available forever" to provide a convenient and consistent user experience, the dynamic (loading when needed and destroying when idle) of resource-intensive view instances, combined with a clear final cleanup mechanism, effectively avoids the persistent resource problem of traditional pre-installed applications that are "resident in memory and only increase without decreasing".

[0071] In some embodiments, combined with Figure 2 As shown, the control method for automotive applications-free services includes the following steps: S201, when the access device is identified, a first service instance is created; wherein, the first service instance includes a first service card template and a first dynamic service card view.

[0072] S202, In the event that the first service scenario of the access device fails, delete the first service instance and release the memory resources occupied by the first service instance; wherein, the failure of the first service scenario includes the access device disconnecting or the user actively closing the first service instance.

[0073] S203, when the access device is first identified, a second service instance is created; wherein, the second service instance includes a second service card template and a second dynamic service card view.

[0074] S204 allows users to invoke and use the service multiple times during the life of the second service instance.

[0075] S205, In the event that the second service scenario of the access device fails, delete the second service instance and release the memory resources occupied by the second service instance; wherein, the failure of the second service scenario includes the access device being removed or the user actively uninstalling the second service instance.

[0076] In this embodiment, a dual lifecycle management mechanism that distinguishes between immediate and routine services achieves efficient and precise control of in-vehicle service resources. For plug-and-play devices (such as microphones), a "create-as-you-go, discard-as-you-go" strategy is adopted, dynamically creating service instances and consuming resources only when the device is connected. Once the device is disconnected or the scenario ends, memory is immediately released, avoiding resource waste. For resident devices (such as in-vehicle refrigerators), a "create-once, use-many" strategy is adopted, where service instances can be repeatedly invoked during continuous device connection, and the system automatically optimizes resource consumption when inactive. Through the above differentiated strategies, limited in-vehicle computing and memory resources can be intelligently allocated according to device type and usage scenario, significantly improving resource utilization and system response speed, while ensuring a consistent service experience and stable system operation, thereby enhancing the overall flexibility, scalability, and scenario adaptability of the service framework.

[0077] Combination Figure 3 As shown, the control method for automotive applications-free services includes the following steps: S301, the vehicle-side parses the original protocol data of the devices accessed by the vehicle to obtain a structured device capability description file of the access devices.

[0078] S302, the vehicle uploads a device capability description file and the vehicle's context information to the cloud service platform.

[0079] S303, the cloud service platform receives the device capability description file and vehicle context information sent by the vehicle.

[0080] S304, the cloud service platform generates service card templates based on the device capability description file and contextual information.

[0081] S305, the cloud service platform sends service card templates to the vehicle.

[0082] S306: The vehicle receives the service card template and instantiates and renders it based on the service card template to generate an interactive dynamic service card view.

[0083] S307: The vehicle responds to the user's interactive operations in the dynamic service card view and generates device control commands for the access devices.

[0084] S308, the vehicle sends device control commands to the access device.

[0085] S309, the access device provides services according to the device control command.

[0086] In this embodiment, the vehicle-side is responsible for lightweight real-time parsing of device protocols and raw data collection, ensuring real-time response and low latency. Then, leveraging powerful AI capabilities, the cloud service platform deeply integrates the functions of the access device with multi-dimensional contextual information to dynamically generate service card templates highly adapted to the current scenario, overcoming the limitations of pre-configured static settings. The vehicle-side then performs real-time rendering and interactive processing based on the distributed service card templates, forming a complete control loop from user operation to device execution. This solution effectively overcomes the drawbacks of traditional methods, such as reliance on manual pre-configuration, poor scalability, and fixed scenarios. It achieves seamless support for diverse and rapidly iterating access devices and can adjust the service interface and logic in real time according to changes in the scenario, thereby significantly improving the flexibility, adaptability, and user experience of in-vehicle services.

[0087] Combination Figure 5 The present disclosure provides a control device 500 for automotive application-free services, including a processor 50 and a memory 51, and may also include a communication interface 52 and a bus 53. The processor 50, communication interface 52, and memory 51 can communicate with each other via the bus 53. The communication interface 52 can be used for information transmission. The processor 50 can call logical instructions in the memory 51 to execute the control method for automotive application-free services described in the above embodiment.

[0088] Furthermore, the logic instructions in the aforementioned memory 51 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0089] The memory 51, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 50 executes functional applications and data processing by running the program instructions / modules stored in the memory 51, thereby implementing the control method for automotive application-free services in the above method embodiments.

[0090] The memory 51 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 51 may include high-speed random access memory and may also include non-volatile memory.

[0091] Processor 50 is a circuit with signal processing capabilities. In one implementation, processor 50 can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, processor 50 can implement certain functions through the logical relationships of hardware circuits. These logical relationships of hardware circuits are fixed or reconfigurable. For example, processor 50 can be a hardware circuit implemented as an ASIC or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above modules. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), or deep learning processing unit (DPU). The processor 50 is used to execute related programs to implement the functions required by the units in the control device for automotive applicationless services according to the embodiments of this application, or to execute the control method for automotive applicationless services according to the method embodiments of this application.

[0092] As can be seen, each module in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor types.

[0093] Furthermore, the modules in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these modules are integrated together as a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or for implementing the functions of the modules of the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and artificial intelligence processor, CPU and GPU, etc.

[0094] By employing a control device for automotive application-free services, service card templates are generated based on device capability description files and contextual information. These service card templates no longer rely on pre-set static logic but can perform real-time and intelligent reorganization of interface elements and functional adaptation according to the current access device and scenario environment. The vehicle end performs real-time data binding and rendering based on the service card template, forming a dynamic service card view that can dynamically evolve with changes in access devices, scenario switching, and user status. This significantly improves the scenario adaptability of the in-vehicle service interface and enhances the user experience.

[0095] This disclosure provides an embodiment of a vehicle 60, combined with... Figure 6 As shown, the vehicle 60 includes a vehicle body 600; the aforementioned control device 500 for vehicle-to-everything (V2X) services is disposed on the vehicle body 600.

[0096] This disclosure provides a computer-readable storage medium storing computer-executable instructions configured to perform the aforementioned control method for automotive application-free services.

[0097] This disclosure provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the aforementioned control method for automotive application-free services.

[0098] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0099] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code; it can also be a transient storage medium.

[0100] The foregoing description and accompanying drawings fully illustrate embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included or substituted for parts and features of other embodiments. The scope of the embodiments of this disclosure includes the entire scope of the claims and all available equivalents of the claims. While the terms “first,” “second,” etc., may be used in this application to describe elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be called a second element without changing the meaning of the description, and similarly, a second element may be called a first element, provided that all occurrences of “first element” are consistently renamed and all occurrences of “second element” are consistently renamed. First and second elements are both elements, but may not be the same element. Moreover, the terminology used in this application is only for describing embodiments and is not intended to limit the claims. As used in the description of the embodiments and claims, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to also include the plural forms. Similarly, the term “and / or” as used herein means including one or more of the associated listed any and all possible combinations. Additionally, when used herein, the terms “comprise” and its variations “comprises” and / or “comprising” refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase “comprising an…” does not exclude the presence of additional identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0101] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0102] The methods and products disclosed in the embodiments herein (including but not limited to devices and equipment) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A control method for automotive applications-free services, characterized in that, include: Parse the raw protocol data of the devices connected to the vehicle to obtain a structured device capability description file of the connected devices; Upload the device capability description file and the vehicle's context information to the cloud service platform, and obtain the service card template generated by the cloud service platform based on the device capability description file and context information; The service card template is instantiated and rendered to generate an interactive, dynamic service card view. In response to user interactions in the dynamic service card view, device control commands are generated for the access devices to control the access devices to provide services.

2. The control method according to claim 1, characterized in that, Parse the raw protocol data of the devices connected to the vehicle to obtain a structured device capability description file, including: The original protocol data is parsed to identify key metadata of the access device; the key metadata includes one or more of the following: access device type, brand, function instruction set, data read / write format, status variables, and encoding rules. Key metadata is converted into a structured description file in a unified format, which serves as the device capability description file.

3. The control method according to claim 1, characterized in that, Upload the device capability description file and the vehicle's context information to the cloud service platform, and obtain a service card template generated by the cloud service platform based on the device capability description file and context information, including: Collect vehicle context information; this context information includes vehicle status, environmental data, and user information. The device capability description file and context information are uploaded to the cloud service platform so that the cloud service platform can generate a service card template adapted to the current scenario based on the device capability description file and context information. The service card template defines the interactive interface, data logic and calling interface in a structured language.

4. The control method according to claim 3, characterized in that, Based on the device capability description file and context information, a service card template adapted to the current scenario is generated, including: The device functions defined in the device capability description file are mapped to service atoms that can be invoked, and a scene vector representing the current scene is formed based on the context information. The target service mode is determined based on the scene vector, and the interface components are selected and arranged from the component library according to the target service mode to form the interface layout. Bind the interface layout to the service atoms to generate service card templates.

5. The control method according to claim 1, characterized in that, Based on the service card template, instantiate and render to generate an interactive, dynamic service card view, including: Based on the interface structure and data binding relationship defined in the service card template, obtain the current vehicle data; Bind and instantiate the current vehicle data and service card template, and render a dynamic service card view.

6. The control method according to claim 1, characterized in that, In response to user interactions in the dynamic service card view, generate device control commands for the access devices, including: Capture user interaction events with the dynamic service card view; Based on the logic defined in the service card template, call the cloud interface to process interactive events and generate device control commands.

7. The control method according to any one of claims 1 to 6, characterized in that, Also includes: When an access device is identified, a first service instance is created; wherein, the first service instance includes a first service card template and a first dynamic service card view; If the first service scenario of the access device fails, delete the first service instance and release the memory resources occupied by the first service instance; wherein, the failure of the first service scenario includes the access device disconnecting or the user actively closing the first service card view.

8. The control method according to any one of claims 1 to 6, characterized in that, Also includes: A second service instance is created when the access device is first identified; wherein, the second service instance includes a second service card template and a second dynamic service card view; During the lifetime of the second service instance, users can invoke and use it multiple times; If the second service scenario of the access device fails, delete the second service instance and release the memory resources occupied by the second service instance; wherein, the failure of the second service scenario includes the access device being removed or the user actively uninstalling the second service card view.

9. A control device for automotive applications-free services, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to execute, when running the program instructions, the control method for automotive applicationless services as described in any one of claims 1 to 8.

10. A car, characterized in that, include: The car body; The control device for automotive non-application services as described in claim 9 is disposed on the vehicle body.

Images