Software-defined automobile system and method

Abstract

The invention discloses a software-defined automobile system and method, and relates to the technical field of vehicle engineering, and the software-defined automobile system comprises a cloud subsystem and an automobile end execution layer which are in communication connection; the cloud subsystem comprises a plug-in management platform used for receiving, storing and managing a vehicle interface packaging plug-in provided by a developer; the workflow arrangement platform is used for a developer to arrange a workflow for realizing business logic based on a tool function provided by the plug-in; the resource publishing platform is used for publishing the plug-in and the workflow through a message pushing mechanism or a query interface; the vehicle end execution layer comprises a computing center engine used for acquiring the plug-in and the workflow, loading and executing the plug-in and the workflow and providing a calling interface; the vehicle interface unit is used for providing basic control capability for vehicle hardware and vehicle end application; and the vehicle end application is used for calling a calling interface of the computing center engine and operating a vehicle interface unit by executing the plug-in or the workflow.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle engineering, and in particular to a system and method for software-defined automobile. BACKGROUND

[0002] The automobile software architecture generally adopts a tightly coupled firmware mode, in which the functional logic of the vehicle is deeply integrated with the underlying operating system and hardware driver, and is deployed and updated in the form of a whole-vehicle firmware image; under this architecture, any modification or addition of business logic for vehicle functions such as air conditioning control, seat adjustment, and ambient light scene, even if it involves only a minor adjustment of a single function, requires recompilation, integration, and testing of the entire firmware package, and ultimately upgrading through a large-scale whole-vehicle OTA method.

[0003] However, this technical solution based on whole-vehicle firmware upgrade has significant inherent defects, with a lengthy update process that typically takes months and consumes huge network bandwidth and cloud computing resources. SUMMARY

[0004] The present application aims to provide a system and method for software-defined automobile, at least one of which solves the problem of a lengthy update process that typically takes months and consumes huge network bandwidth and cloud computing resources.

[0005] The present application provides the following solutions:

[0006] According to one aspect of the present application, a system for software-defined automobile is provided, comprising a cloud subsystem and a vehicle-side execution layer connected in communication;

[0007] The cloud subsystem comprises:

[0008] a plug-in management platform for receiving, storing, and managing vehicle interface encapsulation plug-ins provided by developers, and performing version management and dependency resolution on the plug-ins;

[0009] a workflow orchestration platform for developers to orchestrate workflows implementing business logic based on tool functions provided by the plug-ins;

[0010] a resource publishing platform for publishing plug-ins and workflows through a message pushing mechanism or a query interface;

[0011] The vehicle-side execution layer comprises:

[0012] a computing center engine for obtaining the plug-ins and workflows, loading and executing them, and providing a calling interface;

[0013] A vehicle interface unit for providing basic control capabilities for vehicle hardware and vehicle-side applications, including a vehicle bottom-layer hardware driver interface and a cockpit application service interface;

[0014] A vehicle-side application for invoking the invocation interface of the computing center engine to operate the vehicle interface unit by executing the plug-in or workflow.

[0015] Further, the steps of receiving, storing, and managing the plug-in include:

[0016] Receiving a vehicle interface package plug-in uploaded by a developer in a predefined format;

[0017] Verifying the integrity and security of the plug-in;

[0018] Storing metadata information of the plug-in and performing version management on the plug-in.

[0019] Further, the step of the vehicle interface package plug-in performing vehicle model adaptation includes:

[0020] Obtaining the vehicle model, vehicle series, and configuration information of the current vehicle through the vehicle identification interface inside the plug-in;

[0021] Selecting a corresponding bottom-layer interface call path according to the vehicle feature information;

[0022] Providing a unified tool function interface to the upper-layer application.

[0023] Further, the step of the orchestration implementing the workflow of business logic includes:

[0024] Providing a workflow development environment based on a script language;

[0025] Allowing the developer to select tool functions from the plug-in library and sequentially orchestrate them according to business logic;

[0026] Supporting setting conditional judgment logic in the workflow.

[0027] Further, the step of publishing the plug-in and the workflow includes:

[0028] Proactively sending update notifications to the vehicle-side execution layer through a message push mechanism;

[0029] Providing a query interface for the vehicle-side execution layer to pull the latest plug-in and workflow resources;

[0030] Supporting incremental updates of the plug-in and the workflow.

[0031] Further, the step of loading and executing the plug-in and the workflow includes:

[0032] Using a class loader to dynamically load the plug-in package and resolve its dependency relationship;

[0033] loading the workflow using a script interpreter and establishing a call association between the workflow and the plug-in tool functions;

[0034] registering the loaded plug-in and workflow into the execution environment and establishing a name index mapping.

[0035] Further, the step of the computing center engine processing the vehicle-side application request comprises:

[0036] receiving a call request from the vehicle-side application;

[0037] selecting to execute a single plug-in tool function or a complete workflow according to the request type;

[0038] executing a specific vehicle control operation through the vehicle interface unit and returning a result.

[0039] Further, the step of the system performing end-to-cloud collaboration comprises:

[0040] the cloud-side subsystem continuously develops and optimizes vehicle interface encapsulation plug-ins and business workflows;

[0041] the resource publishing platform publishes the updated plug-ins and workflows to the vehicle-side execution layer;

[0042] the vehicle-side execution layer dynamically loads and executes the latest plug-ins and workflows.

[0043] Further, the step of the system performing security management comprises:

[0044] performing security scanning on the uploaded plug-ins;

[0045] performing permission control on the execution of the plug-ins and workflows;

[0046] recording the execution logs of the plug-ins and workflows.

[0047] According to the two aspects of the present application, a method for software-defined vehicles is provided, comprising:

[0048] receiving, storing and managing vehicle interface encapsulation plug-ins provided by developers;

[0049] based on the tool functions provided by the plug-ins, orchestrating workflows for implementing business logic;

[0050] publishing the plug-ins and workflows to the vehicle side;

[0051] obtaining the plug-ins and workflows from the cloud side;

[0052] loading and executing the obtained plug-ins and workflows;

[0053] In response to a call of the vehicle-side application, vehicle function control is implemented by executing the plug-in or the workflow.

[0054] Through the above scheme, the following beneficial technical effects are obtained:

[0055] Through the cooperation of the cloud plug-in management platform and the workflow arrangement platform, the implementation of the vehicle function business logic is decoupled from the underlying firmware; this enables the addition of new functions or the optimization of existing functions without going through a lengthy whole-vehicle OTA firmware upgrade cycle, and only requires the updated plug-in or workflow to be incrementally issued to the vehicle side through the resource publishing platform, and to be dynamically loaded and executed by the computing center engine; thereby shortening the function update cycle from months to days or even hours, significantly improving software delivery efficiency and vehicle function evolution speed.

[0056] Through the internal integration of vehicle model recognition and adaptation logic, the application provides a unified tool function interface to the upper layer application; this design encapsulates the processing of vehicle model differences in the plug-in, so that business application developers do not need to be concerned about the specific configuration of the underlying hardware; the same set of business logic can be automatically adapted and executed on different vehicle models by loading different standardized plug-ins, greatly reducing the development, testing and maintenance cost of multi-vehicle software, and achieving one arrangement and full-line adaptation.

[0057] Through the flexible conditional judgment logic supported by the Lua script language and the like, the workflow can dynamically adjust the execution path according to real-time vehicle state, environmental parameters or user characteristics; this enables the vehicle function to change from a preset fixed logic to a contextual-aware and intelligent decision-making scenario-based service, such as automatically setting a personalized air conditioning mode according to the driver's gender and environmental temperature, thereby improving user experience and the intelligent level of vehicle services.

[0058] Through the security management process, including plug-in upload scanning, runtime permission control, complete execution log auditing and digital signature verification, a full-link security protection system is built from development, publishing to execution; it is ensured that only authenticated and authorized code can be executed on the vehicle, effectively preventing malicious code attacks and unauthorized access to the vehicle system, and providing a safe and reliable basic environment for third-party developers to participate in vehicle application innovation.

[0059] Through the performance data and abnormal logs generated during the execution of the vehicle side, the cloud analysis platform can be fed back, providing data support for the continuous optimization of plug-ins and workflows; this end-cloud collaborative mechanism enables the vehicle system to continuously iterate and evolve based on real running data, forming a digital closed loop of development-deployment-feedback-optimization, so that the vehicle can continuously obtain function improvement and experience improvement in the whole life cycle. BRIEF DESCRIPTION OF DRAWINGS

[0060] Figure 1 This is an architecture diagram of a software-defined vehicle system provided by one or more embodiments of the present invention.

[0061] Figure 2 This is a flowchart of a software-defined vehicle method provided by one or more embodiments of the present invention. Detailed Implementation

[0062] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0063] Figure 1 This is an architecture diagram of a software-defined vehicle system provided by one or more embodiments of the present invention.

[0064] like Figure 1 The software-defined vehicle system shown includes a cloud subsystem for communication connectivity and a vehicle-side execution layer;

[0065] The cloud subsystem includes:

[0066] The plugin management platform is used to receive, store, and manage vehicle interface encapsulation plugins provided by developers, and to perform version management and dependency resolution for the plugins.

[0067] Further steps for receiving, storing, and managing plugins include:

[0068] Receive vehicle interface encapsulation plugins in predefined formats uploaded by developers;

[0069] Verify the integrity and security of the plugin;

[0070] Store plugin metadata information and manage plugin versions.

[0071] Furthermore, the vehicle interface encapsulation plugin performs vehicle model adaptation steps including:

[0072] The plugin obtains the current vehicle's model, series, and configuration information through a vehicle recognition interface.

[0073] Select the corresponding underlying interface call path based on the vehicle characteristic information;

[0074] Provides a unified utility function interface for upper-layer applications.

[0075] Specifically, software-defined vehicle systems, through methods such as... Figure 1The architecture shown enables dynamic expansion and standardized encapsulation of vehicle capabilities; the cloud subsystem's plugin management platform is responsible for receiving vehicle interface encapsulation plugins uploaded by developers through a secure transmission protocol. These plugins are compiled and encapsulated using a predefined bytecode format, such as an executable library file generated based on the Android Dex standard, to ensure cross-platform compatibility.

[0076] During the plugin acceptance phase, the platform verifies the integrity of the plugin package by checking its digital signature and hash value. Specifically, the SHA-256 algorithm is used to calculate the hash value and compare it with the authentication information provided by the developer. Security verification includes static code analysis to detect whether the plugin contains unauthorized system calls or resource access instructions. After successful verification, the platform parses the plugin's metadata information, including the plugin package name, class name, list of utility functions, version number, and list of dependent libraries, and stores this information in a distributed database. At the same time, a version history is established, supporting semantic version control strategies, such as managing compatibility changes through major version number, minor version number, and revision number.

[0077] The vehicle interface encapsulation plugin executes vehicle model adaptation logic at runtime. First, it obtains the current vehicle's model code, vehicle series identifier, and hardware configuration parameters by calling the vehicle identification interface. This information comes from the vehicle bus system or cloud configuration services. The adaptation process uses configuration mapping functions to convert hardware parameters to standardized interfaces, the mathematical expression of which is as follows:

[0078]

[0079] in Represents the standardized parameter set, Represents a set of hardware-specific parameters. This represents the vehicle configuration mapping function, which is implemented by querying a preset configuration table or dynamically loading adaptation rules. For example, in the air conditioning control plugin, the mapping function will automatically include fragrance control parameters for the fragrance function of high-end models, while such parameters will be ignored for low-end models. Finally, the plugin provides services to upper-layer applications through a unified utility function interface, such as providing standardized temperature settings or mode switching methods, thereby hiding the underlying hardware differences.

[0080] The entire operation process reflects the complete chain from plugin upload and verification to dynamic adaptation, ensuring the standardized encapsulation and flexible expansion of vehicle interfaces.

[0081] A workflow orchestration platform is used by developers to orchestrate workflows that implement business logic based on utility functions provided by plugins.

[0082] Furthermore, the steps for orchestrating a workflow to implement business logic include:

[0083] Provides a workflow development environment based on scripting languages;

[0084] It allows developers to select utility functions from the plugin library and arrange them in order of business logic;

[0085] Supports setting conditional judgment logic in workflow.

[0086] Specifically, the workflow orchestration platform provides developers with an integrated development environment based on scripting languages. This environment includes two working modes: a visual editor and a code editor. It supports combining plugins, utility functions through graphical drag-and-drop or by directly writing scripts.

[0087] The development environment dynamically loads a list of registered plugin utility functions by calling the standard interface provided by the plugin management platform, and displays it to developers in a searchable tree structure. Developers can select the required utility functions from the plugin library, such as the temperature setting function in the air conditioning control plugin and the on / off control function in the seat heating plugin, and drag and drop these functions into the editing area to arrange them in order according to business logic requirements. During the arrangement process, the platform verifies the parameter compatibility and data type matching between functions in real time to ensure the continuity of workflow logic.

[0088] For the implementation of conditional judgment logic, the platform provides a condition node editing function, supporting branch judgment based on vehicle state variables, environmental parameters, or user input; the conditional judgment logic can be directly expressed through scripting languages, for example, using the following form of conditional expression:

[0089]

[0090] in This indicates the result of the branch execution judgment. Represents the vehicle state vector. Represents a set of environmental parameters. This represents user input data. This represents a conditional judgment function; in specific applications, it can be set to automatically execute a combination of seat heating and steering wheel heating when the driver is detected to be female and the ambient temperature is below a set threshold.

[0091] After the workflow is edited, the platform performs syntax checks and logic validations, including detecting disconnected data streams, circular dependencies, and parameter type conflicts. Workflows that pass validation are compiled into an intermediate representation format and appended with necessary metadata information, including the workflow version number, the list of required plugin dependencies, and execution permission configurations.

[0092] The final generated workflow is distributed to the vehicle-side execution layer through the resource publishing platform, and dynamically loaded and executed by the workflow interpreter in the computing center engine. This implementation method, through an editing environment that combines visualization and scripting, not only lowers the technical threshold for business logic orchestration, but also maintains the flexibility and accuracy of workflow definition.

[0093] The resource publishing platform is used to publish plugins and workflows through message push mechanisms or query interfaces;

[0094] Furthermore, the step of publishing the plugins and workflows includes:

[0095] Update notifications are proactively sent to the vehicle-side execution layer via a push notification mechanism.

[0096] Provides a query interface for the vehicle-side execution layer to pull the latest plugins and workflow resources;

[0097] Supports incremental updates for plugins and workflows.

[0098] Specifically, the resource publishing platform ensures that plugins and workflow resources can be efficiently and reliably distributed to the vehicle-side execution layer through a dual-channel mechanism; the platform maintains a resource version repository, which stores plugin packages and workflow scripts that have undergone rigorous testing and verification, and each resource comes with complete version metadata and a digital signature;

[0099] The message push mechanism is implemented based on the publish-subscribe pattern. When a new plugin version or workflow update is detected, the platform sends an update notification to the subscribed vehicle-side execution layer via the MQTT protocol. The notification message is encapsulated in a lightweight JSON format and contains key metadata such as resource identifier, version number, update type, and resource size. To adapt to different network environments, the push mechanism supports message priority settings. Critical security updates will be marked as high priority to ensure timely delivery.

[0100] The query interface adopts a RESTful architecture to provide resource retrieval services for the vehicle-side execution layer. The vehicle can query the latest version of a specific resource via HTTP / HTTPS protocol. The interface response includes the resource's download address, MD5 checksum, and dependency information. To improve query efficiency, the platform has established a resource index caching mechanism and supports filtering by vehicle model configuration, regional strategy, and other conditions.

[0101] The incremental update function achieves efficient resource transfer through a differential algorithm; the platform uses the bsdiff algorithm to compare the old and new versions of resource files and generate a patch package containing only the differences; this process can be described by the following formula:

[0102]

[0103] in This represents the generated difference data blocks. This indicates the new version's resource content. This indicates the content of the old version of the resource. This represents the difference calculation function; after the vehicle obtains the difference package, it uses the corresponding synthesis algorithm to merge the difference content with the existing local version to completely restore the new version resources;

[0104] To ensure transmission reliability, the platform implements a segmented verification mechanism, calculating a CRC32 checksum for each resource block; the vehicle terminal verifies data integrity in real time during the download process, and automatically requests retransmission when a corrupted block is detected; at the same time, the platform supports breakpoint resume function, realizing interruption recovery by recording the transmission progress status;

[0105] The version management strategy follows the principle of forward compatibility. The platform maintains a resource compatibility matrix to ensure that the vehicle can correctly identify and handle version dependencies. When the system version of the vehicle is detected to be incompatible with the resource requirements, the platform will automatically recommend a compatible alternative version or provide necessary upgrade guidance.

[0106] The entire resource publishing process embodies a complete technology chain from update detection, notification push, difference calculation to reliable transmission. This implementation method, through a dual mechanism combining message push and query interface, ensures both the timeliness of resource updates and the reliability of transmission in complex network environments. The application of incremental update technology significantly reduces network bandwidth consumption and improves update efficiency during large-scale vehicle deployments.

[0107] The vehicle-side execution layer includes:

[0108] The computing center engine is used to acquire the plugins and workflows, load and execute them, and provide calling interfaces;

[0109] Further steps for loading and executing plugins and workflows include:

[0110] Use a class loader to dynamically load plugin packages and resolve their dependencies;

[0111] Load the workflow using a script interpreter and establish the association between the workflow and the call to the plugin utility function;

[0112] Register the loaded plugins and workflows to the execution environment and establish a name index mapping.

[0113] Furthermore, the steps by which the computing center engine processes vehicle-side application requests include:

[0114] Receive call requests from the vehicle-side application;

[0115] Choose to execute a single plugin utility function or the entire workflow based on the request type;

[0116] The vehicle interface unit performs specific vehicle control operations and returns the results.

[0117] Specifically, the computing center engine completes the full functionality from resource acquisition to instruction execution through a multi-stage processing flow. When the engine starts, it first establishes a connection with the resource publishing platform, obtains the list of available plugins and workflow resources through the query interface, and verifies the resource signature and integrity.

[0118] The class loader uses a parent delegation model to dynamically load plugin packages and creates corresponding class objects by parsing Dex format bytecode files. During the dependency resolution phase, the loader checks the list of dependency libraries declared by the plugin and satisfies the plugin's runtime requirements through dependency injection. For missing dependencies, the system automatically obtains supplementary resources from the resource publishing platform to ensure the integrity of the plugin's runtime environment.

[0119] The script interpreter implements workflow loading functionality based on the Lua virtual machine. During interpreter initialization, a bridge is established with the plugin runtime environment, enabling workflow scripts to directly call loaded plugin utility functions. Call association is achieved by establishing a function mapping table, which maintains the correspondence between script function names and actual plugin method addresses.

[0120] The name index mapping is implemented using a hash table data structure, with the plugin name and workflow name as keys to quickly locate the corresponding execution unit; the engine maintains a global registry, recording the metadata of all available plugins and workflows, including version number, function description and access permissions;

[0121] When a request is received from a vehicle-side application, the engine first parses the request parameters to identify the target resource type and the invocation method. Depending on the request type, the execution path selection algorithm determines whether to invoke a single plugin utility function or the entire workflow. This selection process can be described by the following logical expression:

[0122]

[0123] in Indicates the request type identifier. This indicates that a single plugin path will be executed. Indicates the execution workflow path;

[0124] For plugin invocation, the engine quickly locates the target plugin instance through name index mapping and calls the corresponding utility function through Java reflection mechanism; for workflow execution, the interpreter parses the script instructions line by line, controls the execution flow based on condition judgment logic, and calls the plugin utility function to complete the specific operation when appropriate.

[0125] Vehicle control operations are executed through the vehicle interface unit. The engine converts standardized parameters into control commands that are recognized by the underlying hardware. An exception handling mechanism is used during execution to capture runtime errors and record detailed logs. The operation results are returned to the caller after being formatted, including the execution status code and return data.

[0126] The entire processing flow embodies a complete technical chain from resource loading and request parsing to instruction execution. This implementation method, through the combination of dynamic loading and interpreted execution, ensures both the scalability of the system and the safety and reliability of vehicle control operations. Multi-level verification mechanisms and exception handling strategies provide effective guarantees for the stable operation of the system.

[0127] The vehicle interface unit provides basic control capabilities for vehicle hardware and vehicle-side applications, including vehicle-level hardware driver interfaces and cockpit application service interfaces.

[0128] Specifically, the vehicle interface unit, as the core interaction hub between the system and vehicle hardware and in-vehicle applications, achieves unified encapsulation of control capabilities at different abstraction levels through a layered architecture. During the system initialization phase, this unit establishes a connection with the vehicle bus system and application framework, and loads the corresponding communication protocol stack and driver module.

[0129] Vehicle hardware control capabilities are provided through the vehicle's underlying API layer, which includes a sensor data acquisition module and an actuator control module. The data acquisition module reads vehicle status information via CAN bus or AUTOSAR architecture, including but not limited to real-time parameters such as vehicle speed, motor speed, battery level, and door status. The actuator control module converts standardized control commands into specific signals that the underlying hardware can recognize, such as converting a uniform temperature setpoint into a PWM waveform signal that the air conditioning controller can process.

[0130] Application control capabilities are implemented through the application interface (API) layer, which establishes communication channels with various applications in the in-vehicle infotainment system. The API supports multiple interaction modes, including application status query, interface navigation, and function trigger execution. For example, the playback control of the music application can obtain the playback status and switch playlists through a standardized interface, while the navigation application supports destination setting and route planning query.

[0131] The parameter conversion module is responsible for handling the mapping relationship between different data formats. It uses the following conversion function to convert standardized parameters into specific control signals:

[0132]

[0133] in This indicates the generated control signal. Indicates standardized input parameters. Indicates hardware configuration parameters, This represents a parameter conversion function; the conversion process takes into account hardware characteristics and the current state of the vehicle to ensure the safety and effectiveness of control commands.

[0134] The safety verification module performs multi-layer verification before the command is executed, including parameter range checking, command conflict detection, and system status assessment. For operations involving safety-critical functions, the module implements additional confirmation mechanisms. For example, when both acceleration and braking commands are received simultaneously, the module selects the safety command to execute based on a preset priority strategy.

[0135] The exception handling mechanism monitors the instruction execution status in real time. When a hardware response timeout or execution exception is detected, the recovery process is automatically triggered. The system records detailed execution logs, including instruction sending time, hardware response time, and execution result status code, providing data support for fault diagnosis.

[0136] The vehicle interface unit exposes available interfaces to the computing center engine through a service registration mechanism. The engine obtains the list of supported functions and parameter formats by querying the interface capability description. This design allows upper-layer applications to control vehicle functions uniformly without worrying about the differences in the underlying hardware, simply by using standardized interfaces.

[0137] The entire technical solution achieves unified abstraction and management of vehicle hardware resources and application service capabilities through layered design and standardized interfaces; the modular architecture enables the system to flexibly adapt to the hardware configurations of different vehicle models while maintaining interface consistency and scalability; the organic combination of security verification mechanisms and exception handling strategies ensures the reliable execution of vehicle control operations in complex environments.

[0138] The vehicle-side application is used to call the call interface of the computing center engine and operate the vehicle interface unit by executing plugins or workflows.

[0139] Specifically, the vehicle-side application establishes a communication connection with the computing center engine through a standardized calling interface, enabling flexible invocation of plug-in functions and workflow services; when the application starts, it first queries the computing center engine for the list of currently available plug-ins and workflow resources, and obtains their function descriptions and calling specifications;

[0140] The API calls adopt a standardized design based on an interface definition language, supporting both synchronous and asynchronous calling modes. Applications construct calling requests according to business needs, and the request parameters include the target resource identifier, function name, input parameter sequence, and calling mode identifier. Parameter serialization uses cross-language data formats such as JSON or Protocol Buffers to ensure platform independence of data structures.

[0141] For calls to plugin utility functions, the application accurately locates the target plugin by function name and namespace. Input parameters are passed to the computing center engine after type checking and range validation. The engine calls the corresponding plugin method through reflection mechanism. The execution process includes parameter type conversion and return value formatting.

[0142] Workflow calls are triggered by specifying the workflow name and initial parameters. Applications do not need to know the specific execution logic inside the workflow. The computing center engine parses the workflow definition file and executes the condition judgments and plugin call sequences in sequence. The intermediate results generated during the process are temporarily stored and managed by the workflow engine.

[0143] The call process adopts a unified exception handling mechanism. When a plugin is not found, a function call fails, or a parameter is incorrect, the system returns a standardized error code and description. The application can decide on a retry strategy or switch to a backup plan based on the error type. For example, it can automatically switch to the basic temperature control mode when the air conditioning control plugin call fails.

[0144] The execution result is returned to the application via a callback interface or message queue. The result data includes the execution status code, return value, and detailed timestamp information. After parsing the result, the application updates the interface display or triggers subsequent business logic. For example, in the intelligent scene mode, the vehicle cabin environment is automatically adjusted according to the workflow execution result.

[0145] The entire invocation process embodies a complete technical chain from resource discovery, request construction, execution distribution to result processing. This implementation method, through standardized interfaces and a unified error handling mechanism, ensures both the ease of application development and the reliability of the system in complex scenarios. The coexistence of plugin and workflow invocation modes provides comprehensive support for vehicle-side applications, ranging from simple function calls to complex business processes.

[0146] Furthermore, the steps for the system to perform edge-cloud collaboration include:

[0147] The cloud subsystem continues to develop and optimize vehicle interface encapsulation plugins and business workflows;

[0148] The resource publishing platform will publish the updated plugins and workflows to the vehicle-side execution layer;

[0149] The vehicle-side execution layer dynamically loads and executes the latest plugins and workflows.

[0150] Specifically, the edge-cloud collaboration mechanism enables the continuous evolution of system functions by establishing a complete digital closed loop; the development platform in the cloud subsystem provides developers with a complete plugin and workflow development toolchain, supporting full-process management from code writing, testing and verification to version release;

[0151] During development, the cloud platform continuously optimizes plug-in algorithms and workflow logic by collecting operational data and performance indicators from the vehicle end; for example, it differentiates and optimizes air conditioning control strategies based on the environmental characteristics and user habits of different regions; the version control system establishes a complete change record for each modification to ensure code traceability.

[0152] The resource release platform adopts a canary release strategy, where new versions of plugins and workflows are first tested and verified on a small number of vehicles. The platform compares the performance of different versions through A / B testing and collects key indicators such as execution success rate, response time, and resource consumption. Once the new version passes verification, the platform generates the official release package and updates the major version number in the resource version repository.

[0153] The vehicle-side execution layer obtains resource update notifications through a timed polling mechanism or a real-time push channel. When a new version of a resource is detected, the execution environment first verifies the digital signature and integrity check value to ensure the resource source is trustworthy. After verification, the system executes the corresponding loading process according to the resource type.

[0154] The dynamic loading process employs hot update technology to ensure that the system can complete functional updates without downtime. For plugin resources, the computing center engine creates new class instances through the class loader while maintaining the reference count of the old version instance. The old version is safely uninstalled after all currently executing tasks are completed. For workflow resources, the script interpreter re-parses the updated logic definition and the new business process takes effect immediately.

[0155] The execution environment establishes a version rollback mechanism. When a compatibility issue or performance degradation is detected in a new version, it automatically switches to the previous stable version. The rollback decision is based on a preset health metric, and the version stability score can be calculated using the following formula:

[0156]

[0157] in This indicates the version stability score. Indicates the success rate of execution. Indicates the average response time. This represents the resource consumption index. These are the corresponding weighting coefficients;

[0158] The vehicle-side system regularly uploads operational status reports to the cloud, including resource usage, performance metrics, and abnormal event records. The cloud-based analytics platform aggregates and analyzes this data to identify system bottlenecks and optimization opportunities, generating new development requirements.

[0159] This edge-cloud collaborative architecture achieves a complete closed loop from requirement discovery, development and testing, release and deployment to operational feedback; through a data-driven continuous optimization mechanism, the system can adaptively improve its functional features and continuously enhance the user experience; a hierarchical release strategy and an automated rollback mechanism ensure the security and controllability of the system update process; and through deep collaboration between cloud intelligence and vehicle-side execution, the continuous evolution and optimization of vehicle functions are achieved.

[0160] Furthermore, the system performs security management steps including:

[0161] Perform a security scan on the uploaded plugins;

[0162] Implement access control for the execution of plugins and workflows;

[0163] Record the execution logs of plugins and workflows.

[0164] Specifically, the system ensures the safe and reliable operation of plugins and workflows through a multi-layered security protection mechanism; the security management module loads security policy configuration files during the system initialization phase to establish a complete security protection system.

[0165] Security scanning of uploaded plugins employs a combination of static analysis and dynamic detection. In the static analysis phase, the security engine parses the plugin's bytecode, constructs control flow and data flow graphs, and detects vulnerabilities such as dangerous system calls, unauthorized resource access, or code injection. In the dynamic detection phase, the plugin executes in an isolated sandbox environment, monitoring its runtime behavior, including memory access patterns, system call sequences, and network connection requests. The security assessment results are used to calculate a risk score using the following formula:

[0166]

[0167] in This indicates the plugin's risk score. This represents the static analysis risk value. This indicates the dynamic detection risk value. Indicates the developer's reputation rating. These are the weighting coefficients for each indicator;

[0168] The access control module is based on a role-based access control model, assigning clear permission levels to each plugin and workflow. When loading a plugin, the execution environment checks its declared permission requirements and verifies them against the current security policy. For operations involving critical vehicle functions, the system implements a multi-level approval mechanism, requiring explicit user authorization before execution. The permission verification process is implemented through an access control matrix, where rows represent the main plugins and workflows, columns represent the object system resources, and matrix elements define specific access permissions.

[0169] The execution log system uses a structured recording format to fully record the lifecycle events of plugins and workflows. Log entries include execution timestamps, caller identity, target resources, input parameters, execution results, and performance metrics. To ensure log integrity, the system uses hash chain technology to continuously encrypt and protect log records, preventing tampering.

[0170] The log analysis engine processes the collected runtime data in real time and detects abnormal behavior through pattern recognition algorithms. When it detects continuous failed calls, unauthorized access attempts, or abnormal access to resources, the system automatically triggers security alerts and takes corresponding protective measures. For example, when it detects that a plugin is frequently accessing unauthorized resources, the system can automatically suspend its execution and notify the security administrator.

[0171] The security audit module regularly generates security reports, summarizing the system's security status, risk events, and compliance status. The report data comes from the monitoring results of various security components, and after aggregation and analysis, an overall security posture assessment is formed. These assessment results are fed back to the cloud development platform to provide data support for subsequent plugin development and security strategy optimization.

[0172] The entire safety management process embodies a complete safety protection system from prevention, detection, and response; through multi-level safety control measures and continuous safety monitoring, the system can effectively prevent safety threats and ensure the reliable operation of the vehicle system; the dynamic adjustment mechanism of the safety strategy enables the system to adapt to the ever-changing safety environment and maintain the effectiveness of its protective capabilities.

[0173] Figure 2 This is a flowchart of a software-defined vehicle method provided by one or more embodiments of the present invention.

[0174] like Figure 2 One software-defined vehicle method shown includes:

[0175] Receive, store, and manage vehicle interface encapsulation plugins provided by developers;

[0176] Based on the utility functions provided by the plugin, orchestrate workflows to implement business logic;

[0177] Publish plugins and workflows to the vehicle;

[0178] Get plugins and workflows from the cloud;

[0179] Load and execute the acquired plugins and workflows;

[0180] In response to calls from vehicle-side applications, vehicle function control is achieved by executing plugins or workflows.

[0181] Specifically, during the cloud processing stage, the plugin management platform verifies the developer's identity through digital certificates and then receives the vehicle interface encapsulation plugins submitted by the developer. These plugins are developed using standardized interface specifications and include predefined input and output parameters and exception handling mechanisms. The workflow orchestration platform, based on a graphical editing interface, connects multiple plugin utility functions according to business logic to form an execution flowchart that includes conditional judgment nodes and loop control structures. The orchestrated workflow is managed through version control tools to ensure the traceability of each modification.

[0182] During the resource release phase, the platform performs compatibility verification on the new version of the resources to ensure that they match the hardware configuration and system version of the target vehicle model. The release process adopts a canary release strategy, and the initial release range is calculated using the following formula:

[0183]

[0184] in This indicates the number of vehicles deployed in the first batch. Indicates compatibility score. Indicates the functional criticality coefficient. This is a configurable scaling factor;

[0185] During the vehicle-side processing phase, the computing center engine obtains incremental resource packages through a differential update mechanism, reducing the amount of data transmitted over the network. During the loading process, the execution environment verifies resource signatures and checks the integrity of dependencies to ensure that the runtime environment meets the requirements. The execution engine supports individual calls to plug-in utility functions and sequential execution of the complete workflow, automatically selecting the optimal execution path based on the call context.

[0186] In specific application scenarios, taking AVAS (Acoustic Vehicle Alert System) sound control as an example, the system encapsulates the audio generation hardware interface of different vehicle models through a dedicated plug-in. The workflow dynamically adjusts the warning sound type and volume according to the vehicle speed, gear status and ambient noise level. When the system detects that the vehicle is traveling at low speed and the surrounding environment is noisy, it automatically triggers the enhanced warning sound mode and generates a warning sound that meets regulatory requirements through a parameterized audio synthesis algorithm.

[0187] The entire approach embodies a complete technology chain from cloud development to vehicle-side execution, enabling flexible definition and secure deployment of vehicle functions through standardized interfaces and modular design. The approach ensures the efficiency and reliability of system updates through resource version management and differential update mechanisms, while maintaining compatibility with existing systems. The hierarchical execution environment provides appropriate isolation and protection for different types of vehicle functions, ensuring that critical safety functions are not affected by updates to non-critical functions.

[0188] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A system for software-defined vehicles, characterized in that The software-defined vehicle system comprises a cloud subsystem and a vehicle-side execution layer connected by communication; The cloud subsystem comprises: a plug-in management platform for receiving, storing and managing vehicle interface package plug-ins provided by developers, and performing version management and dependency resolution on the plug-ins; a workflow orchestration platform for enabling developers to orchestrate workflows implementing business logic based on tool functions provided by the plug-ins; a resource publishing platform for publishing the plug-ins and workflows through a message pushing mechanism or a query interface; The vehicle-side execution layer comprises: a computing center engine for obtaining the plug-ins and workflows, loading and executing them, and providing a calling interface; a vehicle interface unit for providing basic control capabilities for vehicle hardware and vehicle-side applications, including vehicle bottom-layer hardware driver interfaces and cockpit application service interfaces; a vehicle-side application for calling the calling interface of the computing center engine to operate the vehicle interface unit by executing the plug-ins or workflows.

2. The system for software defined car of claim 1, wherein, The steps of receiving, storing and managing the plug-ins comprise: receiving vehicle interface package plug-ins of a predefined format uploaded by developers; verifying the integrity and security of the plug-ins; storing metadata information of the plug-ins and performing version management on the plug-ins.

3. The system for software defined car of claim 1, wherein, The steps of performing vehicle model adaptation by the vehicle interface package plug-ins comprise: obtaining the vehicle model, series and configuration information of the current vehicle through a vehicle identification interface inside the plug-in; selecting a corresponding bottom-layer interface calling path according to the vehicle feature information; providing a unified tool function interface to the upper-layer application.

4. The system for software defined car of claim 1, wherein, The steps of orchestrating workflows implementing business logic comprise: providing a workflow development environment based on a script language; allowing developers to select tool functions from a plug-in library and sequentially orchestrate them according to business logic; supporting setting of conditional judgment logic in the workflows.

5. The system for software defined car of claim 1, wherein, The steps of publishing the plug-ins and workflows comprise: actively sending update notifications to the vehicle-side execution layer through a message pushing mechanism; providing a query interface for the vehicle-side execution layer to pull the latest plug-in and workflow resources; supporting incremental update of the plug-ins and workflows.

6. The system for software defined car of claim 1, wherein, The steps of loading and executing the plug-ins and workflows comprise: dynamically loading plug-in packages using a class loader and resolving their dependencies; loading workflows using a script interpreter and establishing calling association between the workflows and plug-in tool functions; registering the loaded plug-ins and workflows to an execution environment and establishing name index mapping.

7. The system for software defined car of claim 1, wherein, The steps of the computing center engine processing vehicle-side application request comprise: receiving calling requests from the vehicle-side application; selecting execution of a single plug-in tool function or a complete workflow according to the request type; performing specific vehicle control operations through the vehicle interface unit and returning results.

8. The system for software defined car of claim 1, wherein, The steps of the system performing end-to-cloud collaboration comprise: the cloud subsystem continuously develops and optimizes vehicle interface package plug-ins and business workflows; the resource publishing platform publishes the updated plug-ins and workflows to the vehicle-side execution layer; the vehicle-side execution layer dynamically loads and executes the latest plug-ins and workflows.

9. The system for software defined car of claim 1, wherein, The steps of the system performing security management comprise: performing security scanning on uploaded plug-ins; performing permission control on execution of the plug-ins and workflows; recording execution logs of the plug-ins and workflows.

10. A method of software-defined vehicle, characterized by, The software-defined vehicle method comprises: Receiving, storing and managing vehicle interface package plug-ins provided by developers; Based on tool functions provided by the plug-ins, orchestrating work flows to implement business logic; Publishing the plug-ins and work flows to the vehicle end; Obtaining the plug-ins and work flows from the cloud; Loading and executing the obtained plug-ins and work flows; In response to a call of the vehicle end application, implementing vehicle function control by executing the plug-ins or work flows.

Images