SOA service architecture-based vehicle-mounted terminal control method and vehicle-mounted terminal system

Abstract

The invention provides a vehicle-mounted terminal control method and a vehicle-mounted terminal system based on SOA (service oriented architecture), and the method comprises the steps: enabling a function to enter a judgment stage, enabling a video entertainment domain controller to obtain a vehicle state signal through calling a standardized service interface, carrying out the precondition judgment from the dimension of a user operation scene, and obtaining a vehicle state signal; if the precondition is not met, prompt information is directly generated on a terminal interface; in the function execution link design stage, for a combined function needing cooperation of at least two other domain controllers, the audio and video entertainment domain controller sends independent action instructions to the other domain controllers respectively by calling atomization service interfaces in the standardized service interfaces in parallel; in the function memory mode design stage, the main control logic is deployed in the audio and video entertainment domain controller, data memory and calling are executed by the audio and video entertainment domain controller on setting items and position parameters changing along with user accounts, and the audio and video entertainment domain controller achieves data storage and calling by calling a parameter configuration service interface.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of vehicle control, in particular to a vehicle terminal control method based on SOA service architecture and a vehicle terminal system. BACKGROUND

[0002] With the rapid development of intelligent vehicles, the vehicle operation terminal has become an indispensable important component of vehicles, which includes multiple display terminals such as central control screen, co-pilot screen, rear entertainment screen, armrest screen, etc., and can set the functions of multiple domains such as vehicle body, power, intelligent driving, chassis, etc. Through convenient ways such as voice interaction and touch operation, the vehicle operation terminal can improve the driving experience and safety, and make the vehicle a mobile personalized space.

[0003] However, the current vehicle operation terminal does not form a reasonable architecture control method based on the flexibility of service-oriented architecture (SOA), resulting in a large number of redundant designs, unnecessary signal interactions, and increased controller burden. At the same time, there is a lack of unified vehicle terminal control method based on SOA architecture, and the software versions of different vehicle models are different, which brings a lot of repetitive work and secondary development cost to designers.

[0004] Although the existing SOA service architecture control method can realize the optimization of power management, vehicle body domain function, functional safety, etc., it focuses on specific function design and safety optimization, lacks a systematic control method for vehicle terminal architecture, and cannot meet the adaptation requirements of frequent interactions and multiple triggered functions of vehicle terminal. Therefore, there is an urgent need for a vehicle terminal control method based on SOA service architecture to solve the problems of serious function coupling, signal redundancy, and low software reuse rate. SUMMARY

[0005] The present disclosure aims to solve at least one of the technical problems existing in the prior art and proposes a vehicle terminal control method based on SOA service architecture and a vehicle terminal system.

[0006] In a first aspect, the embodiments of the present disclosure provide a vehicle terminal control method based on SOA service architecture, applied to a system including an audio-visual entertainment domain controller and at least two other domain controllers, the audio-visual entertainment domain controller being configured to control the terminal interface of at least one display screen, the SOA service architecture providing a standardized service interface, the standardized service interface including at least an atomized service interface and a parameter configuration service interface, the method comprising:

[0007] The function enters a judgment stage, the audio-visual entertainment domain controller obtains vehicle state signals by calling the standardized service interface, judges the precondition from the user operation scene dimension, and generates prompt information directly on the terminal interface if the precondition is not met; after the audio-visual entertainment domain controller sends a control instruction to the other domain controllers, the other domain controllers judge the redundancy condition from the execution safety dimension, and feed back fault diagnosis information to the audio-visual entertainment domain controller through the standardized service interface when the judgment fails, and the audio-visual entertainment domain controller converts the fault diagnosis information into prompt information and displays it on the terminal interface;

[0008] In the function execution link design stage, for a combined function requiring cooperation of at least two other domain controllers, the audio-visual entertainment domain controller sends independent action instructions to each of the other domain controllers by parallel calling of the atomized service interface in the standardized service interface, and only adjusts the service calling combination of the audio-visual entertainment domain controller when the combined function requirement changes.

[0009] In the function memory mode design stage, the function setting item whose main control logic is deployed in the audio-visual entertainment domain controller and requires execution of no less than two other domain controllers, and the location type parameter which varies with the user account, are all executed by the audio-visual entertainment domain controller for data memory and calling, the audio-visual entertainment domain controller realizes data storage and calling by calling the parameter configuration service interface, and the other domain controllers only perform mechanical actions according to the received instructions.

[0010] In some embodiments, the precondition judgment of the user operation scene dimension includes obtaining vehicle scene state signals.

[0011] The generation mode of the prompt information is:

[0012] The function entry area of the terminal interface is executed with gray-out or hidden processing, or a pop-up window is triggered to display operation guidance text when the user touches.

[0013] In some embodiments, the redundancy condition judgment of the execution safety dimension includes internal hardware fault states and actuator feedback abnormal states of the other domain controllers,

[0014] The internal hardware fault states and actuator feedback abnormal states are collected by the other domain controllers and do not participate in the precondition judgment of the user operation scene dimension.

[0015] The fault diagnosis information includes fault codes and fault source positioning information, which are converted into natural language text by the audio-visual entertainment domain controller through a preset mapping relationship and superimposed with graphical identifiers on the terminal interface for display.

[0016] In some embodiments, the combined function is a scenario mode function, and the atomic service interface includes at least a seat adjustment service interface, an air conditioning control service interface, a lighting control service interface, and a window control service interface. The audio-visual entertainment domain controller realizes multi-system linkage control by calling multiple service interfaces in parallel.

[0017] In some embodiments, when the execution parameters of the combined function change, the audio-visual entertainment domain controller modifies the stored configuration data by calling the parameter configuration service interface to achieve function iteration, and the other domain controllers do not need to update their software versions.

[0018] In some embodiments, the location parameters that change with the user account include seat position, rearview mirror angle, and steering wheel height. The audio-visual entertainment domain controller stores the above parameters in percentage coordinates and sends coordinate value instructions directly to the corresponding other domain controllers when the account logs in or switches.

[0019] In some embodiments, the standardized service interface is defined based on the AUTOSAR Adaptive Platform or COVESA / VSS service description specification, unifying the input and output data format and interaction logic of the interface;

[0020] The communication protocol between the audio-visual entertainment domain controller and the other domain controllers uses SOME / IP.

[0021] Secondly, embodiments of this disclosure provide an in-vehicle terminal system based on an SOA service architecture, including:

[0022] The audio-visual entertainment domain controller is configured to execute the method provided in the first aspect, including service interface calls, functional logic judgments, setting item data storage, and generation of prompts on the terminal interface;

[0023] At least two other domain controllers are configured to receive instructions sent by the AV domain controller through a standardized service interface and execute corresponding actions, while simultaneously feeding back execution status information to the AV domain controller;

[0024] At least one in-vehicle display screen is electrically connected to the audio-visual entertainment domain controller and is configured to display the terminal interface and prompt information;

[0025] The SOA service layer, deployed on the vehicle Ethernet gateway or central computing platform, is configured to provide the standardized service interface and realize loosely coupled communication between the audio-visual entertainment domain controller and other domain controllers through service registration, service discovery and service routing functions.

[0026] Thirdly, embodiments of this disclosure provide an electronic device, including:

[0027] One or more processors;

[0028] Memory, used to store one or more programs;

[0029] When one or more programs are executed by one or more processors, the one or more processors implement the vehicle terminal control method based on SOA service architecture provided in the first aspect.

[0030] Fourthly, embodiments of this disclosure provide a computer-readable medium storing a computer program, which, when executed by a processor, implements the vehicle terminal control method based on SOA service architecture provided in the first aspect. Attached Figure Description

[0031] Figure 1 A schematic diagram of the structure of an in-vehicle terminal system based on SOA service architecture provided in an embodiment of this disclosure;

[0032] Figure 2 A flowchart illustrating a vehicle terminal control method based on an SOA service architecture provided in this disclosure embodiment;

[0033] Figure 3 A flowchart illustrating another vehicle terminal control method based on SOA service architecture provided in this disclosure embodiment;

[0034] Figure 4 A flowchart illustrating a precondition determination method provided in an embodiment of this disclosure;

[0035] Figure 5 This is a schematic diagram of a link design for combined functions provided in an embodiment of the present disclosure;

[0036] Figure 6a A memory diagram of the main controller of an audio-visual entertainment domain controller provided in this embodiment of the present disclosure;

[0037] Figure 6b This disclosure provides a schematic diagram illustrating the memory of account settings.

[0038] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0039] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0040] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0041] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0042] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0043] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0044] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example, appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely identifying specific individuals.

[0045] With the rapid development of intelligent vehicles, in-vehicle operating terminals have become an indispensable component. Modern vehicles are generally equipped with multiple display terminals such as central control screens, passenger screens, rear entertainment screens, and armrest screens. These terminals not only allow for centralized settings of functions across multiple domains, including body, powertrain, intelligent driving, and chassis, but also enhance the driving experience and safety through intelligent technologies such as voice interaction and touch operation, transforming the vehicle into a personalized mobile space. The numerous functions of in-vehicle operating terminals result in a large number of signal interaction links between the audio-visual entertainment domain controller and other domain controllers. The rationality of the architecture design directly affects development costs, functional stability, and system security.

[0046] Service-Oriented Architecture (SOA), as an advanced software architecture paradigm, decomposes application functions into independent, reusable service units. Through standardized interfaces, it achieves loosely coupled communication, significantly improving system reusability, scalability, and maintenance efficiency, making it particularly suitable for handling complex vehicle application scenarios. However, current in-vehicle operating terminals do not fully leverage the flexibility of SOA architecture. The lack of a unified and reasonable terminal architecture control method leads to significant redundant design: on the one hand, the mixed nature of function triggering and execution logic generates unnecessary signal interactions, increasing the controller's burden; on the other hand, different vehicle models lack unified design guidelines, resulting in significant software version differences. Designers are required to perform a large amount of repetitive work and secondary development, leading to wasted development resources and fluctuations in delivery quality.

[0047] Existing SOA service architecture control methods mostly focus on localized areas such as power management, vehicle body function implementation, or functional safety optimization, and have not yet formed systematic and platform-based design specifications for the core component of the in-vehicle terminal, which involves high-frequency interaction and multi-screen linkage. Specifically, this manifests in several ways: First, precondition judgment is concentrated in the execution controller. When a user triggers a function, the AV domain controller only sends a simple control signal, and only reports a failure status when the controller determines that the precondition is not met. This makes it difficult for users to intuitively understand the specific reason why the function cannot be activated. Second, for complex combined functions such as scenario modes that require the collaboration of multiple controllers, traditional solutions rely on a single controller to carry all the logic. When functional requirements change, multiple controller software must be modified simultaneously, resulting in high coupling and high maintenance costs. Third, regarding function memory mechanisms, although parameters such as seat position and rearview mirror angle that change with the user account are primarily controlled by the AV domain controller, the execution controller still remembers the specific values, failing to fully utilize the rich computing and storage resources of the AV domain controller, leading to logical redundancy and resource waste.

[0048] Therefore, there is an urgent need for a vehicle terminal control method based on SOA service architecture, which systematically optimizes the entire link from function triggering, execution to memory, clarifies the responsibilities of each domain controller, realizes true functional decoupling and platform reuse, minimizes redundant signal interaction, reduces cross-vehicle development costs, and improves software delivery quality while ensuring functional safety.

[0049] To address at least one or more of the aforementioned technical problems, this disclosure provides a vehicle terminal control method and system based on an SOA service architecture, aiming to solve problems such as redundant interaction logic between the vehicle terminal and the domain controller, high functional coupling, and difficulty in cross-vehicle reuse in the prior art.

[0050] Figure 1 This is a schematic diagram of the structure of an in-vehicle terminal system based on an SOA service architecture, as provided in an embodiment of this disclosure. Figure 1 As shown, the system includes an audio-visual entertainment domain controller, at least two other domain controllers, at least one in-vehicle display screen, and an SOA service layer.

[0051] The audio-visual entertainment domain controller is configured to execute the above-mentioned vehicle terminal control method based on SOA service architecture, including service interface calls, functional logic judgments, setting item data storage, and terminal interface prompt generation.

[0052] At least two other domain controllers are configured to receive instructions sent by the AV domain controller through a standardized service interface and execute corresponding actions, while also feeding back execution status information to the AV domain controller.

[0053] At least one in-vehicle display screen is electrically connected to the audio-visual entertainment domain controller and is configured to display the terminal interface and prompt information.

[0054] The SOA service layer is deployed on the vehicle Ethernet gateway or central computing platform. It is configured to provide standardized service interfaces and achieve loosely coupled communication between the audio-visual entertainment domain controller and other domain controllers through service registration, service discovery and service routing functions.

[0055] The vehicle terminal system based on SOA service architecture provided in this disclosure constructs a physically distributed and logically unified SOA service network. It organically combines the strong interactive capabilities of the In-Vehicle Infotainment (IVI) domain controller with the professional execution capabilities of each domain controller, forming a flexible yet stable layered architecture. The SOA service layer, deployed on the gateway or central computing platform, serves as the core architecture of the system, enabling centralized governance and dynamic orchestration of services. It supports service version management, access control, and traffic monitoring, providing a solid platform foundation for the collaborative development of vehicle-level functions. The modular design of the system allows each domain controller to be developed, tested, and upgraded independently, building an open in-vehicle application ecosystem.

[0056] The vehicle terminal control method based on SOA service architecture provided in this disclosure is applied to a system including an audio-visual entertainment domain controller and at least two other domain controllers. The audio-visual entertainment domain controller is configured to control a terminal interface of at least one display screen. The SOA service architecture provides standardized service interfaces, which include at least atomic service interfaces and parameter configuration service interfaces.

[0057] Figure 2 This is a flowchart illustrating a vehicle terminal control method based on an SOA service architecture, as provided in an embodiment of this disclosure. Figure 3 This is a flowchart illustrating another vehicle terminal control method based on SOA service architecture provided in an embodiment of this disclosure. Figure 3 The diagram illustrates the overall architecture and data flow of the in-vehicle terminal design system. For example... Figure 2 As shown, the method includes steps S1-S3:

[0058] Step S1: The function enters the judgment stage. The audio-visual entertainment domain controller obtains the vehicle status signal by calling the standardized service interface and performs a precondition judgment from the perspective of user operation scenario. If the precondition is not met, a prompt message is directly generated on the terminal interface. After the audio-visual entertainment domain controller sends control commands to other domain controllers, the other domain controllers perform redundancy condition judgment from the perspective of execution safety. If the judgment fails, they feed back fault diagnosis information to the audio-visual entertainment domain controller through the standardized service interface. The audio-visual entertainment domain controller converts the fault diagnosis information into a prompt message and displays it on the terminal interface.

[0059] Step S2, Function Execution Link Design Phase: For combined functions that require collaboration from at least two other domain controllers, the AV domain controller sends independent action instructions to each of the other domain controllers by calling the atomic service interfaces in the standardized service interfaces in parallel. When the combined function requirements change, only the service call combination of the AV domain controller is adjusted.

[0060] Step S3, the functional memory design phase, deploys the main control logic on the AV domain controller and the functional settings that need to be executed by no fewer than two other domain controllers, as well as location parameters that change with user accounts. The AV domain controller performs data memory and retrieval. The AV domain controller realizes data storage and retrieval by calling the parameter configuration service interface, and other domain controllers only perform mechanical actions according to the received instructions.

[0061] The vehicle terminal control method based on SOA service architecture provided in this disclosure includes three key design steps. First, in the function entry judgment stage, the scene judgment logic can be moved up to the trigger end, reducing redundant signal transmission and reception, avoiding invalid command transmission and unnecessary bus communication load. Second, in the service-oriented design of the function execution link, each other domain controller only executes mechanical actions according to the received instructions, without being aware of logical changes in the upper-layer combined functions. This achieves complete decoupling of functional logic and execution logic, significantly reducing software development costs when iterating across vehicle models or functions, and improving response flexibility and maintenance efficiency. Third, in the optimization of the function memory method, data storage and retrieval are achieved by calling the parameter configuration service interface. Other domain controllers only execute mechanical actions according to the received coordinate instructions, clearly defining the responsibilities of each domain controller, achieving true functional decoupling and platform-based reuse. This ensures a clear separation between memory logic and execution logic, minimizing redundant signal interactions while guaranteeing safe operation.

[0062] Furthermore, in this embodiment of the disclosure, the precondition judgment for the user operation scenario dimension includes obtaining vehicle scenario status signals. These vehicle scenario status signals can be, for example, driver's seat belt buckle status, door opening / closing status signals, or other relevant scenario status signals, and are not specifically limited here. Moreover, this embodiment of the disclosure also clarifies the method for generating prompt information.

[0063] Figure 4 This is a flowchart illustrating a precondition determination method provided in an embodiment of the present disclosure. In some embodiments, such as... Figure 4 As shown, the precondition judgment of the user operation scenario dimension includes obtaining the vehicle scenario status signal, such as the driver's seat belt buckle status, the door opening and closing status signal, etc. The prompt information is generated by: performing graying or hiding processing in the function entry area of ​​the terminal interface, or triggering a pop-up window to display operation guidance text when the user touches the screen.

[0064] The reason for specifying these particular signals is that they represent the most basic safety and scenario constraints, serving as general prerequisites for high-frequency functions such as automatic parking and cruise control. By graying out or hiding the function entry area on the terminal interface, a pre-emptive warning of function unavailability can be displayed before user operation, avoiding invalid clicks. Conversely, triggering a pop-up window to display operation guidance text during user touch operation provides immediate and clear operation guidance for scenarios where the user actively attempts to access the system. The technical effect of this differentiated prompt strategy is that it balances interface simplicity with the effectiveness of user guidance, avoiding excessive user interference while providing necessary information at key points, significantly reducing user learning costs and improving perceived function usability. In practical applications, after the IVI retrieves these status signals from the service capability library, it completes the judgment locally and renders the interface feedback in real time, without waiting for the controller to respond. This reduces response latency from the network communication level to the local processing level, resulting in a smoother user experience.

[0065] Furthermore, in this embodiment of the disclosure, the redundancy condition judgment content for the execution security dimension is refined to include the internal hardware fault status of other domain controllers and the abnormal feedback status of actuators, and it is stipulated that these statuses are collected by other domain controllers and do not participate in the precondition judgment of the user operation scenario dimension.

[0066] In some embodiments, the redundancy condition judgment for the security dimension includes the internal hardware fault status of other domain controllers and the abnormal status of actuator feedback. The internal hardware fault status and the abnormal status of actuator feedback are collected by other domain controllers and do not participate in the precondition judgment of the user operation scenario dimension; the fault diagnosis information includes fault codes and fault source location information, which are converted into natural language text by the audio-visual entertainment domain controller through a preset mapping relationship and superimposed with graphical labels for display on the terminal interface.

[0067] The aforementioned redundant condition judgments completely separate the two types of judgments, avoiding confusion caused by overlapping judgment logic. Internal hardware fault states refer to low-level hardware problems such as MCU failure, sensor malfunction, and communication module anomalies in the controller itself, while actuator feedback anomalies refer to execution-level faults such as motor stall and position sensor misalignment. These state judgments rely on local hardware diagnostic information from the controller. Remote judgment via IVI would introduce a large amount of real-time diagnostic signal transmission, increasing bus load and resulting in poor timeliness. Therefore, retaining the judgments locally on the controller is the most reasonable technical choice.

[0068] The fault diagnosis information includes fault codes and fault source location information, such as "the left front wheel speed sensor signal under the chassis controller is lost". The audio-visual entertainment domain controller converts it into natural language text such as "automatic parking function is temporarily unavailable: left front wheel speed sensor fault" through preset mapping relationship and displays it on the terminal interface with graphical labels.

[0069] In this way, on the one hand, the performance overhead and real-time challenges caused by complex hardware diagnostics by IVI are avoided, and on the other hand, by standardizing the fault information format and mapping conversion mechanism, the fault information of controllers from different vendors can be presented to users in a unified and user-friendly manner, thereby improving the system's diagnosability and cross-platform compatibility.

[0070] Furthermore, this embodiment of the disclosure takes the scenario mode function as a typical example, and defines the composition of the atomic service interfaces involved in the combined function. The scenario mode is the most representative combined function of the vehicle terminal, which usually includes multiple scenarios such as "home mode", "away mode" and "rest mode". Each scenario requires the simultaneous adjustment of multiple subsystems. Figure 5 This is a schematic diagram of a combined function link design provided in an embodiment of the present disclosure, illustrating the timing of IVI parallel invocation of multiple controller services in a scenario mode.

[0071] In some embodiments, such as Figure 5 As shown, the combined function is a scenario mode function. The atomic service interface includes at least the seat adjustment service interface, the air conditioning control service interface, the lighting control service interface, and the window control service interface. The audio-visual entertainment domain controller realizes multi-system linkage control by calling multiple service interfaces in parallel.

[0072] like Figure 5 As shown in one example, the IVI calls different service interfaces based on the requirements of the combined functions. For example, functions like scene modes often involve multiple controllers performing actions, such as seat adjustment, air conditioning adjustment, headlight adjustment, and window adjustment. These have been abstracted into various service capabilities through SOA architecture. The IVI can fulfill the requirements of scene modes by calling different service interfaces, avoiding the need to add signals to enable / disable scene modes, thus avoiding redundant signal chains. In another example, the controller receives service call instructions from the IVI and executes the corresponding actions. For example, for the requirements of combined functions, both the windows and suspension need to be adjusted. The body controller and chassis controller can directly execute operations according to the IVI instructions. Even if the requirements of the combined functions change, such as changes in suspension height or window position, the changes to the combined functions can be achieved simply through different service interfaces, avoiding the need to modify the seat controller and headlight controller, thus ensuring low coupling of functions.

[0073] After being abstracted by the SOA architecture, these service interfaces have a unified input / output data format and interaction logic. Regardless of whether the underlying hardware is a stepper motor or a servo motor, the semantics of the interfaces called by the upper layer remain consistent. The audio-visual entertainment domain controller achieves multi-system linkage control by parallelly invoking multiple service interfaces. The parallel invocation mechanism ensures that actions such as seat, air conditioner, lighting, and window can be started synchronously, avoiding the experience fragmentation caused by the traditional serial control timing. By separating the abstract combined function design from the specific atomic service implementation, when adding a new scenario mode or adjusting the parameters of an existing mode, the development work is limited to the service call combination configuration of the IVI application layer, without the need to deeply modify the execution logic of each subsystem controller, shortening the function development cycle from weeks to days, while avoiding the complexity of multi-controller collaborative testing, greatly improving the development efficiency and quality.

[0074] Furthermore, in some embodiments, when the execution parameters of the combined function change, the audio-visual entertainment domain controller modifies the stored configuration data by invoking the parameter configuration service interface to achieve function iteration, and no other domain controllers need to update the software version.

[0075] Taking the scenario mode as an example, if the seat tilt angle of the "rest mode" needs to be adjusted from 30 degrees to 35 degrees, the traditional solution requires recompiling the seat controller software and flashing it, while in this solution, the IVI only needs to update the stored configuration data through the parameter configuration service interface and issue the new coordinate value during the next call. The parameter configuration service interface provides a standardized data access capability, and the configuration data is stored in the IVI local database or the cloud in a structured form.

[0076] That is to say, in the embodiments of the present disclosure, the function logic is parameterized and digitalized, realizing the dynamic adjustment ability during operation, supporting the rapid iteration of functions in the OTA upgrade scenario, avoiding compatibility problems caused by inconsistent software versions, and greatly reducing the full-life cycle maintenance cost.

[0077] Furthermore, in some embodiments, the location parameters that change with the user account include the seat position, the rearview mirror angle, and the steering wheel height. The audio-visual entertainment domain controller stores the above parameters in the form of percentage coordinates and directly sends coordinate value instructions to the corresponding other domain controllers when the account is logged in or switched.

[0078] In a preferred example, the front-back adjustment travel of the seat is 240mm in vehicle model A and 280mm in vehicle model B. Storing the absolute position value will cause cross-vehicle data incompatibility; while using percentage coordinates (0%-100%) has universality. The IVI only needs to remember the user preference ratio, and when issuing instructions, the execution controller of each vehicle model maps it to the actual drive amount according to the locally calibrated physical travel.

[0079] The above embodiments enable seamless migration of user personalized data from the vehicle to the cloud. Preferences set by a user on one vehicle can take effect directly on other vehicles on the same platform without needing to be reset, truly realizing a personalized experience. At the same time, it ensures data compatibility between platform-based vehicle models, supporting the OEM's large-scale application strategy.

[0080] Figure 6a This is a memory diagram of a master controller for an audio-visual entertainment domain controller provided in an embodiment of the present disclosure. Figure 6b This disclosure provides a schematic diagram of memory for follow account settings. This disclosure fully utilizes the service capability library extracted from the SOA architecture, clearly defining the principles and methods for IVI function memory, thereby achieving full utilization of IVI performance and resources.

[0081] like Figure 6a As shown, the main control is in the IVI (Interactive Visual Identity), with multiple (≥2) execution controllers. The IVI memorizes the settings. For example, functions like scene modes involve complex actions. Since the main control is in the IVI, the IVI memorizes the scene mode settings. If settings change, the IVI can handle the changes uniformly, reducing redundant logic from multiple memory operations by the controllers. Figure 6b As shown, settings that change with the account are memorized by the IVI. For example, each time the account is logged in or switched, the seat / rearview mirror / steering wheel needs to be adjusted to the user-set driving position. Through the service capabilities abstracted by the SOA architecture, the IVI can obtain the specific percentage position set by the user. Each time the account is switched, the IVI can directly call the percentage coordinate interface to move the seat / rearview mirror / steering wheel. Compared to the IVI issuing driving position commands, the controller memorizing the position and executing actions fully utilizes the IVI's performance and storage resources.

[0082] Furthermore, in some embodiments, the standardized service interface is defined based on the AUTOSAR Adaptive Platform or COVESA / VSS service description specification, unifying the input and output data format and interaction logic of the interface; the communication protocol between the audio-visual entertainment domain controller and other domain controllers adopts SOME / IP.

[0083] These two specifications were chosen because AUTOSAR Adaptive Platform is a recognized software architecture standard for high-performance computing platforms in the automotive industry, providing comprehensive communication mechanisms and service interface definition languages; COVESA / VSS (Vehicle Signal Specification) focuses on the standardized description of vehicle signals, facilitating data interoperability across brands and platforms. Defining service interfaces based on these specifications ensures service interoperability and portability. It also specifies that the communication protocol between the AV domain controller and other domain controllers adopts SOME / IP. SOME / IP, as the recommended service communication protocol of AUTOSAR, is suitable for high-performance Ethernet communication within vehicles. The technical advantage of this claim is that by adopting an industry-standard protocol stack, it avoids vendor lock-in issues caused by proprietary protocols, enabling controllers from different vendors to seamlessly access the SOA service network, reducing supply chain risks, and facilitating third-party application developers to develop innovative functions based on a unified interface, building an open automotive application ecosystem.

[0084] In summary, the vehicle terminal control method based on SOA service architecture provided in this disclosure deeply integrates the advantages of SOA service architecture, constructing a complete, reusable, and loosely coupled vehicle terminal platform solution. It not only solves the redundancy and coupling problems of existing technologies, but also significantly improves development efficiency, user experience, and system maintainability without increasing hardware costs, thus possessing broad industry application value.

[0085] Based on the same inventive concept, this disclosure also provides an electronic device. Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this disclosure. Figure 7 As shown, this disclosure provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the SOA-based vehicle terminal control methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processors and the memory, configured to enable information interaction between the processors and the memory.

[0086] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0087] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0088] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0089] This disclosure also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the SOA-based vehicle terminal control methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0090] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described vehicle terminal control method based on SOA service architecture.

[0091] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0092] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0093] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0094] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0095] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0096] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0097] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0098] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0099] 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 various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction 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 those 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. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may 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.

[0100] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A vehicle terminal control method based on SOA service architecture, applied to a system including an audio-visual entertainment domain controller and at least two other domain controllers, wherein the audio-visual entertainment domain controller is configured to control a terminal interface of at least one display screen, the SOA service architecture provides standardized service interfaces, the standardized service interfaces including at least atomic service interfaces and parameter configuration service interfaces, characterized in that, The method includes: Once the function enters the judgment phase, the audio-visual entertainment domain controller obtains the vehicle status signal by calling the standardized service interface, performs a precondition judgment from the perspective of user operation scenario, and if the precondition is not met, it directly generates a prompt message on the terminal interface; after the audio-visual entertainment domain controller sends control commands to the other domain controllers, the other domain controllers perform redundancy condition judgment from the perspective of execution safety, and if the judgment fails, they feed back fault diagnosis information to the audio-visual entertainment domain controller through the standardized service interface, and the audio-visual entertainment domain controller converts the fault diagnosis information into a prompt message and displays it on the terminal interface; During the function execution chain design phase, for combined functions that require collaboration from at least two other domain controllers, the audio-visual entertainment domain controller sends independent action instructions to each of the other domain controllers by calling the atomic service interfaces in the standardized service interfaces in parallel. When the combined function requirements change, only the service call combination of the audio-visual entertainment domain controller is adjusted. During the functional memory design phase, the main control logic is deployed on the audio-visual entertainment domain controller, and the functional settings items that need to be executed by no fewer than two other domain controllers, as well as the location parameters that change with the user account, are all stored and retrieved by the audio-visual entertainment domain controller. The audio-visual entertainment domain controller realizes data storage and retrieval by calling the parameter configuration service interface, and the other domain controllers only perform mechanical actions according to the received instructions.

2. The method according to claim 1, characterized in that, The precondition judgment for the user operation scenario dimension includes obtaining vehicle scenario status signals. The prompt message is generated in the following way: The function entry area of ​​the terminal interface is grayed out or hidden, or a pop-up window is triggered to display operation guidance text when the user touches the screen.

3. The method according to claim 1, characterized in that, The redundancy condition judgment for the execution security dimension includes the internal hardware fault status of other domain controllers and the abnormal feedback status of the actuator. The internal hardware fault status and actuator feedback abnormal status are collected by the other domain controllers and are not involved in the precondition judgment of the user operation scenario dimension. The fault diagnosis information includes fault codes and fault source location information. The audio-visual entertainment domain controller converts these into natural language text through a preset mapping relationship and overlays graphical icons to display them on the terminal interface.

4. The method according to claim 1, characterized in that, The combined function is a scenario mode function. The atomic service interface includes at least a seat adjustment service interface, an air conditioning control service interface, a lighting control service interface, and a window control service interface. The audio-visual entertainment domain controller realizes multi-system linkage control by calling multiple service interfaces in parallel.

5. The method according to claim 1, characterized in that, When the execution parameters of the combined function change, the audio-visual entertainment domain controller modifies the stored configuration data by calling the parameter configuration service interface to achieve function iteration, and the other domain controllers do not need to update their software versions.

6. The method according to claim 1, characterized in that, The location parameters that change with the user account include seat position, rearview mirror angle, and steering wheel height. The audio-visual entertainment domain controller stores the above parameters in percentage coordinates and sends coordinate value commands directly to the corresponding other domain controllers when the account logs in or switches.

7. The method according to claim 1, characterized in that, The standardized service interface is defined based on the AUTOSARAdaptive Platform or COVESA / VSS service description specification, unifying the input and output data format and interaction logic of the interface; The communication protocol between the audio-visual entertainment domain controller and the other domain controllers uses SOME / IP.

8. A vehicle-mounted terminal system based on SOA service architecture, characterized in that, include: An audio-visual entertainment domain controller is configured to execute the method of any one of claims 1 to 7, including service interface invocation, functional logic judgment, setting item data storage, and generation of prompts on the terminal interface; At least two other domain controllers are configured to receive instructions sent by the AV domain controller through a standardized service interface and execute corresponding actions, while simultaneously feeding back execution status information to the AV domain controller; At least one in-vehicle display screen is electrically connected to the audio-visual entertainment domain controller and is configured to display the terminal interface and prompt information; The SOA service layer, deployed on the vehicle Ethernet gateway or central computing platform, is configured to provide the standardized service interface and realize loosely coupled communication between the audio-visual entertainment domain controller and other domain controllers through service registration, service discovery and service routing functions.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the vehicle terminal control method based on SOA service architecture as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the vehicle terminal control method based on SOA service architecture as described in any one of claims 1 to 7.

Images