Design method and design system for safety monitoring component of automobile domain controller

Abstract

The invention discloses a safety monitoring component design method and a safety monitoring component design system for an automobile domain controller, and belongs to the technical field of vehicle development. A code generation tool is used for automatically converting the logic model subjected to simulation verification into a core algorithm code, then a vehicle signal is obtained, configuration is loaded, and data interaction with the core algorithm code is carried out; performing cross compiling on a core algorithm code and a code of a platform interface adaptation layer to generate a local binary program capable of running in an Android environment; according to the method, a local binary program is generated, the generated local binary program is integrated into a system mirror image partition of an Android operating system, so that a security monitoring component operates as a system service, and a hybrid development mode combining automatic modeling generation and interface adaptation is adopted, so that the problems of function migration and platform development of the automobile domain controller can be solved, and the development efficiency of the automobile domain controller is improved. The development efficiency is effectively improved; and the development difficulty is reduced.

Description

Technical Field

[0001] This invention relates to the field of vehicle development technology, and in particular to a design method and system for a security monitoring component for an automotive domain controller. Background Technology

[0002] As automotive electronic and electrical architecture evolves from distributed to domain-centralized, the deployment location of functional software also needs to be adjusted accordingly. This is especially true for the development challenges brought about by migrating safety monitoring components from the traditional Vehicle Running Dynamic Control System (VDC, typically running Linux) to the Smart Cockpit Domain Controller (CSC, typically running Android).

[0003] The existing pure code-writing development model typically deploys safety monitoring functions in the VDC before migration, using pure C / C++ code written by hand. This model has the following significant drawbacks: code written by hand for the VDC's Linux environment needs to be almost completely redeveloped when migrating to the CSC's Android environment due to the completely different operating system, system services, and communication mechanisms, resulting in a large workload. Furthermore, it cannot achieve platform reuse for each vehicle model project or each platform migration. Summary of the Invention

[0004] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes a design method for a security monitoring component for automotive domain controllers, which enables a reusable platform-based development solution, improves development efficiency, and effectively reduces development difficulty.

[0005] The present invention also provides a design system and execution device for a security monitoring component for an automotive domain controller.

[0006] A design method for a security monitoring component for an automotive domain controller according to a first aspect of an embodiment of the present invention includes: Use model-based design tools to build logical models of security monitoring rules in a graphical way; The simulation-verified logic model is automatically converted into core algorithm code using a code generation tool. By developing a code development platform interface adaptation layer, vehicle signals can be obtained, configurations can be loaded, and data can be interacted with the core algorithm code. The core algorithm code and the platform interface adaptation layer code are cross-compiled using a cross-compilation toolchain to generate a native binary program that can run in the Android environment. The generated local binary program is integrated into the system image partition of the Android operating system, enabling the security monitoring component to run as a system service.

[0007] The design method for a security monitoring component for an automotive domain controller according to embodiments of the present invention has at least the following beneficial effects: The design method of this invention first uses a model-based design tool to graphically construct a logical model of safety monitoring rules. Then, a code generation tool automatically converts the simulated and verified logical model into core algorithm code, achieving automatic model generation. This function is responsible for implementing the essential logic of all safety monitoring rules. Next, a code development platform interface adaptation layer is written to acquire vehicle signals, load configurations, and interact with the core algorithm code, thus constructing the interface adaptation layer, which is responsible for resolving interaction issues with a specific platform (CSC-Android). Then, a cross-compilation toolchain is used to cross-compile the core algorithm code and the platform interface adaptation layer code, generating a local binary program that can run in the Android environment. The generated local binary program is then integrated into the system image partition of the Android operating system, enabling the safety monitoring component to run as a system service, thereby achieving system deployment and integration. This invention adopts a hybrid development model combining automatic model generation and interface adaptation, which can solve the problems of vehicle domain controller function migration and platform development, effectively improving development efficiency and reducing development difficulty.

[0008] According to some embodiments of the present invention, the step of using a modeling design tool to graphically construct a logical model of security monitoring rules includes: Use Matlab / Simulink tools to build an input processing module for signal filtering and standardization, a scheduling control module for timed triggering calculations, a logic calculation module for implementing multiple monitoring rules, and an output integration module for summarizing results; The input processing module, the scheduling control module, the logic calculation module, and the output integration module are laid out in a layered architecture.

[0009] According to some embodiments of the present invention, the step of developing a code development platform interface adaptation layer to obtain vehicle signals, load configurations, and interact with the core algorithm code includes: Write code to interact with the vehicle middleware SDK and obtain the required vehicle signals in real time; The vehicle signals are converted and packaged, and then provided to the core algorithm layer as input. The core algorithm layer is an algorithm model based on the core algorithm code. Write code to call the entry function of the core algorithm layer and drive the core algorithm layer to perform calculations on the converted and packaged data files to obtain the output results of data interaction.

[0010] According to some embodiments of the present invention, the step of developing a code development platform interface adaptation layer to obtain vehicle signals, load configurations, and interact with the core algorithm code further includes: Write code to parse external configuration files and dynamically load settings for function switches and parameter thresholds, then pass them to the core algorithm layer to enable configuration for different vehicle models.

[0011] According to some embodiments of the present invention, the design method further includes: The output is encapsulated into a specific format and sent to an external data collection component via a network communication program for communication with the external data collection component.

[0012] According to some embodiments of the present invention, the design method further includes: By customizing the SELinux policy file, the security monitoring component process is granted the minimum set of permissions required to access the network and vehicle signals, in order to meet the Android system security specifications.

[0013] According to a second aspect of the present invention, a security monitoring component design system for an automotive domain controller includes: The graphical modeling module is used to construct logical models of security monitoring rules in a graphical manner using model-based design tools. The code generation module is used to automatically convert the simulation-verified logic model into core algorithm code using code generation tools; The interaction module is used to develop a platform interface adaptation layer by writing code to obtain vehicle signals, load configurations, and interact with the core algorithm code. A cross-platform compilation module is used to cross-compile the core algorithm code and the platform interface adaptation layer code using a cross-compilation toolchain to generate a native binary program that can run in the Android environment. The system deployment module is used to integrate the generated local binary program into the system image partition of the Android operating system, so that the security monitoring component runs as a system service.

[0014] According to some embodiments of the present invention, the graphical modeling module is used to construct, using Matlab / Simulink tools, an input processing module for signal filtering and standardization, a scheduling control module for timed triggering calculations, a logic calculation module for implementing multiple monitoring rules, and an output integration module for summarizing results; and the input processing module, the scheduling control module, the logic calculation module, and the output integration module are laid out in a hierarchical architecture.

[0015] According to some embodiments of the present invention, the interaction module includes a signal interface module, a configuration management module, and a communication output module; The signal interface module is used to write code to interact with the vehicle middleware SDK, acquire the required vehicle signals in real time, convert and package the vehicle signals, and provide them to the core algorithm layer as input. The core algorithm layer is an algorithm model based on the core algorithm code. The configuration management module is used to write code to parse external configuration files and dynamically load function switches and parameter threshold settings, which are then passed to the core algorithm layer to enable configuration for different vehicle models. The communication output module is used to write code to call the entry function of the core algorithm layer and drive the core algorithm layer to perform calculations on the converted and packaged data file to obtain the output results of data interaction.

[0016] The security monitoring component design system for automotive domain controllers according to embodiments of the present invention has at least the following beneficial effects: The design system uses a graphical modeling module and model-based design tools to construct a logical model of safety monitoring rules in a graphical manner. A code generation module automatically converts the simulated and verified logical model into core algorithm code, achieving automatic model generation. This function is responsible for implementing the essential logic of all safety monitoring rules. The interaction module develops a platform interface adaptation layer to acquire vehicle signals, load configurations, and interact with the core algorithm code, thus constructing an interface adaptation layer responsible for resolving interaction issues with a specific platform (CSC-Android). The cross-platform compilation module uses a cross-compilation toolchain to cross-compile the core algorithm code and the platform interface adaptation layer code, generating a local binary program that can run in the Android environment. The system deployment module integrates the generated local binary program into the system image partition of the Android operating system, enabling the safety monitoring component to run as a system service, thereby achieving system deployment and integration. This embodiment of the invention adopts a hybrid development mode combining automatic model generation and interface adaptation, which can solve the problems of vehicle domain controller function migration and platform development, effectively improving development efficiency and reducing development difficulty.

[0017] According to the third aspect of the present invention, the execution device includes at least one processor; and a memory storing instructions that, when executed by the at least one processor, perform the design method for a security monitoring component for an automotive domain controller as described in the first aspect of the above embodiments.

[0018] Since the actuator adopts all the technical solutions of the design method for the security monitoring component of the automotive domain controller described in the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0019] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. Attached Figure Description

[0020] Figure 1 This is a flowchart of a design method for a security monitoring component for an automotive domain controller according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the steps of constructing a logical model in one embodiment of the present invention; Figure 3 This is a flowchart of the development interface adaptation layer steps according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the core algorithm layer and platform-related interface adaptation layer of an embodiment of the present invention; Figure 5 This is a flowchart illustrating an example of a longitudinal following distance too close detection rule in one embodiment of the present invention. Detailed Implementation

[0021] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0022] In the description of this invention, it should be understood that the terms "upper" and "lower" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0023] In the description of this invention, "multiple" means two or more; "greater than," "less than," and "exceeding" are understood to exclude the stated number; "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0024] In the description of this invention, it should be noted that terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0025] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are some embodiments of the present invention, not all embodiments.

[0026] The existing pure hand-written code development model, before migration, typically deploys security monitoring functions in a VDC, using pure C / C++ code written by hand. This model has the following significant drawbacks: 1. Extremely poor platform portability: The code was handwritten for the Linux environment of VDC. When migrating to the Android environment of CSC, due to the completely different operating system, system services, communication mechanisms, etc., it almost needs to be redeveloped, which is a lot of work and costly.

[0027] 2. Low development efficiency and difficulty in guaranteeing quality: Security monitoring involves a large number of complex logical rules (such as collision detection, distance warning, etc.). Writing code manually is not only inefficient, but also prone to human error. The code quality depends heavily on the individual ability of the developers, and the testing and verification cycle is long.

[0028] 3. Inability to achieve platform reuse: Each vehicle model project or each platform migration means a "customized" development process. The code is highly coupled, making it difficult to extract common core parts and form reusable assets, resulting in repetitive work.

[0029] To address the aforementioned issues, this invention aims to combine graphical modeling with automated code conversion. Considering the characteristics of the Android platform, it proposes using an interface adaptation layer to achieve signal acquisition and algorithm interaction, while leveraging cross-compilation technology to solve cross-platform compatibility problems. Through a layered architecture design, the core algorithm is separated from platform-related code, and methods for integrating system services are explored to comply with Android security specifications.

[0030] Reference Figure 1 As shown, this application proposes a design method for a security monitoring component for an automotive domain controller, including the following steps: Step S100: Use a modeling design tool to build a logical model of security monitoring rules in a graphical manner; Step S200: Use a code generation tool to automatically convert the simulation-verified logic model into core algorithm code; Step S300: By writing code to develop the platform interface adaptation layer, vehicle signals are obtained, configurations are loaded, and data interaction is performed with the core algorithm code. Step S400: Use a cross-compilation toolchain to cross-compile the core algorithm code and the platform interface adaptation layer code to generate a local binary program that can run in the Android environment. Step S500: Integrate the generated local binary program into the system image partition of the Android operating system, so that the security monitoring component runs as a system service.

[0031] Among them, model-based design tools refer to visual development environments that build logical rules based on graphical interfaces. Specifically, Matlab / Simulink tools can be used to build signal processing modules, scheduling and control modules, and logic calculation modules, reducing the coupling between modules through layered layout. Code generation tools refer to automated tools that convert the verified logical model into executable code. For example, Embedded Coder can generate C / C++ code that meets the requirements of the target platform, avoiding human coding errors.

[0032] The platform interface adaptation layer refers to the middleware that enables data interaction between the in-vehicle middleware and the core algorithm. Specifically, it obtains raw signal data by calling the in-vehicle SDK, performs format conversion, and then transmits it to the algorithm layer entry function. The cross-compilation toolchain refers to an integrated environment that supports multi-platform code compilation. For example, it uses the Android NDK to compile x86 architecture code into ARM architecture executables, resolving compatibility issues between the Android system and native code. System image partition integration refers to embedding the compiled binary files into the Android system boot image. For example, by modifying the boot partition file, the monitoring component can be automatically loaded as a background service during system startup.

[0033] Specifically, the process begins with constructing a hierarchical model in the graphical modeling stage, encompassing input processing, logical computation, and output integration. Simulation is then used to verify the correctness of the rules. After model verification, the core algorithm code is automatically generated, eliminating the need for manual coding. Adaptation layer code is developed for the Android platform to implement vehicle signal acquisition, configuration loading, and data format conversion. The algorithm code and adaptation layer code are cross-compiled to generate a binary file that can run on the ARM architecture. Finally, this file is written to a designated partition of the Android system image, granting it the permissions and resource access capabilities to run system-level services.

[0034] Compared to existing technologies, traditional development models require complete code rewriting for different platforms. This application, however, decouples the core algorithm from platform code through model-based design, enabling cross-platform reuse of logical rules. Existing technologies rely on manually writing complex logic, which is prone to vulnerabilities. This application uses automated code generation to ensure strict consistency between the algorithm implementation and the model definition. Existing methods require redesigning the communication mechanism on the Android platform, while this application encapsulates platform differences through an interface adaptation layer, significantly reducing migration development workload.

[0035] Through the above technical solutions, this application achieves rapid porting of the safety monitoring component to the Android platform, improving the efficiency of core algorithm code generation and reducing the error rate. The platform interface adaptation layer effectively isolates the vehicle signal acquisition and algorithm calculation stages, enabling the functional modules to be scalable. Cross-compilation and system service integration methods ensure the stable operation of the monitoring component in the target environment, meeting real-time and security requirements. This solution forms a standardized development process, allowing different vehicle model projects to reuse the core model and adaptation layer framework, significantly reducing redundant development investment.

[0036] Reference Figure 2 As shown, in some embodiments, step S100 specifically includes the following steps: Step S110: Use Matlab / Simulink tools to build an input processing module for signal filtering and standardization, a scheduling control module for timed triggering calculations, a logic calculation module for implementing multiple monitoring rules, and an output integration module for summarizing results. Step S120: The input processing module, scheduling control module, logic calculation module and output integration module are laid out in a layered architecture.

[0037] The system comprises the following modules: Input Processing Module (IPM) – This module preprocesses the raw vehicle signals, typically using Simulink's filter module and standardization algorithm to eliminate noise and convert input data of different dimensions into a unified format; Scheduling Control Module (SCCM) – This module periodically triggers computation tasks, typically using Simulink's timer module and state machine model to ensure the logic computation module executes within predetermined time intervals; Logic Computation Module (LCM) – This module executes safety monitoring rules, typically using Simulink's logic operation module and condition judgment module to implement specific business rules such as collision warning and distance detection; and Output Integration Module (ICM) – This module summarizes the computation results, typically using Simulink's data fusion module and format conversion module to generate standardized output data formats. Layered architecture refers to the layout of functional modules according to data flow, typically using model referencing and subsystem encapsulation techniques to establish inter-module calling relationships and data transmission paths.

[0038] Specifically, in the graphical modeling process, four independent functional modules are first created in the Simulink environment. The input processing module converts the raw signals from the vehicle bus into standardized floating-point data by configuring low-pass filters and normalization algorithms. The scheduling control module sends execution instructions to the logic calculation module at fixed intervals through a time-triggered mechanism. The logic calculation module achieves parallel computation of different monitoring rules by building a multi-condition judgment structure. The output integration module integrates discrete calculation results into structured data packets through data caching and format reorganization. The modules are organized using a layered architecture: the input processing module is at the bottom layer, the logic calculation module is in the middle layer, and the scheduling control module and output integration module are in the control layer and output layer, respectively. Data is transferred between layers through well-defined interfaces.

[0039] Through the above technical solutions, this application solves the problem of poor code reusability during the migration of security monitoring functions. The modular structure generated by the graphical modeling tool can be directly adapted to different hardware platforms, and the layered architecture layout reduces the dependencies between functional modules. Business rules are configured visually through the logic calculation module, avoiding logical errors that may occur during manual coding and shortening the functional verification cycle. The standardized module interface design provides a pluggable architectural foundation for subsequent functional expansion, so that when adding monitoring rules, only the corresponding module needs to be modified without refactoring the entire code.

[0040] Reference Figure 3 As shown, in some embodiments, step S300 specifically includes the following steps: Step S310: Write code to interact with the vehicle middleware SDK and obtain the required vehicle signals in real time; Step S320: The vehicle signal is converted, packaged, and provided to the core algorithm layer as input. The core algorithm layer is an algorithm model based on the core algorithm code. Step S330: Write code to call the entry function of the core algorithm layer and drive the core algorithm layer to perform calculations on the converted and packaged data file to obtain the output results of data interaction.

[0041] The vehicle middleware SDK refers to a software development kit used in automotive electronic systems to access vehicle bus data. Specifically, it can be implemented using a communication protocol stack conforming to the AUTOSAR standard to establish communication connections with the vehicle's CAN bus or Ethernet. Conversion and packaging refer to the process of converting raw vehicle signals into a unified data format. This can be achieved using serialization technology to encapsulate multiple signals into binary data blocks, ensuring the core algorithm layer can correctly parse the input data. The core algorithm layer refers to the monitoring rule execution module generated by the model-based design tool. It can be built based on automatically generated C / C++ code and is used to perform calculations such as filtering and logical judgments. The entry function refers to the calling interface exposed by the algorithm module. It can be designed as a function that receives input data pointers and configuration parameters, triggers algorithm execution, and returns the calculation results.

[0042] Specifically, during Android platform development, vehicle signals such as vehicle speed and brake pedal status are read in real time from the CAN bus by calling the API interfaces provided by the automotive middleware SDK. These signals, after normalization, are encapsulated into structured data packets containing timestamps and data identifiers, and passed to the core algorithm layer via shared memory. When the scheduling cycle arrives, the adaptation layer code calls the algorithm module function, passing in the data packet pointer and current configuration parameters, driving the algorithm to complete the monitoring rule calculation. After the calculation result is returned via the pointer address, the adaptation layer converts it to JSON format and stores it in the shared memory area for upper-layer applications to read. Furthermore, by parsing XML format configuration files, braking distance thresholds and fault determination rules for different vehicle models are dynamically loaded, enabling rapid adaptation of the same algorithm module across different vehicle models.

[0043] Through the above technical solution, this application effectively solves the challenges of signal access and algorithm integration when migrating safety monitoring components to the Android platform, achieving decoupling between the vehicle signal acquisition layer and the core algorithm layer. Standardized data interfaces eliminate the need for algorithm modules to adapt to different communication protocols, and the dynamic configuration loading mechanism supports rapid switching of vehicle model parameters via external files, significantly improving code reusability and functional scalability. This solution simplifies the thousands of lines of manually written signal processing code required in traditional development models into configurable, universal interface modules, reducing platform migration workload by approximately 70% and avoiding logical defects caused by human coding errors.

[0044] This application further proposes writing code to parse external configuration files and dynamically load function switches and parameter threshold settings, which are then passed to the core algorithm layer to achieve configuration for different vehicle models.

[0045] The external configuration file refers to a structured data file that stores vehicle configuration information. It can be implemented using XML or JSON format and includes configurable items such as function activation status and monitoring threshold parameters. Function switches are Boolean parameters that control algorithm logic branches, implemented using 0 / 1 flags to dynamically enable or disable specific monitoring rules. Parameter thresholds are the critical values ​​that trigger safety monitoring rules, implemented using floating-point numbers; for example, the collision warning distance threshold can be set to 3.5 meters. Dynamic loading refers to reading the configuration file during program execution, implemented using a file system monitoring mechanism to automatically reload the configuration data when the configuration file is updated.

[0046] Specifically, a configuration management module is established in the platform interface adaptation layer, which reads configuration files stored in a specified directory through a file parser. When a configuration file change is detected, an observer pattern is used to trigger a configuration update event. The parsed function switch states are passed to global variables in the core algorithm layer via memory mapping, while parameter thresholds are passed to the algorithm calculation function via structure pointers. For example, when processing the parking monitoring function for a certain vehicle model, the parking assist function switch state in the configuration file is set to "on," and the minimum safe distance threshold is set to 0.3 meters. These parameters are invoked in real time during algorithm execution. This allows the same core algorithm code to adapt to different vehicle model requirements through external configuration, enabling vehicle model parameter switching without modifying the underlying code.

[0047] Specifically, a specific format refers to a standardized encapsulation form with a predefined data structure, such as JSON or Protobuf, which ensures data parsing consistency across different systems. A network communication program is a software module that implements data transmission functionality, typically using HTTP or MQTT protocol stacks, and its function is to establish cross-platform communication channels. An external data collection component is an independent data processing unit deployed on the target platform, which can be implemented using cloud servers or local database services, and its function is to achieve centralized storage and analysis of monitoring data.

[0048] Specifically, the computation results generated by the core algorithm layer are encapsulated into predefined data structures, such as organizing data fields in key-value pairs. The encapsulated data packets are transmitted via the TCP / IP protocol stack, and the communication program establishes a Socket connection based on the target address. During transmission, the data packets are secured using TLS encryption, and the parsing service deployed at the receiving end performs packet unpacking and verification according to the agreed format. When the data volume reaches a threshold, the communication program automatically activates compression algorithms to reduce network load, such as using Zlib for data stream compression. The data collection component is configured with a status monitoring mechanism at the receiving end to provide real-time feedback on data transmission success rate metrics.

[0049] Through the above technical solution, this application achieves standardized processing of cross-platform transmission of monitoring data, solving the problem of strong coupling between communication modules and operating systems in the traditional handwritten code mode. The unified definition of data encapsulation format makes the communication program platform-independent, and the standardized calling of the network protocol stack allows the communication function to be reused on different vehicle operating systems, effectively reducing the workload of communication module development during platform migration.

[0050] This application further proposes granting security monitoring component processes the minimum set of permissions required to access network and vehicle signals by customizing SELinux policy files, in order to meet Android system security specifications.

[0051] SELinux policy files are configuration files for mandatory access control rules based on security-enhanced Linux. These rules are written in text format and define the access permissions of processes to system resources. This file restricts security monitoring component processes to accessing only specified network ports and vehicle signal interfaces. The minimum permission set refers to containing only the permissions necessary for the security monitoring component to operate. This permission range can be determined by analyzing the component's functional requirements; for example, only opening UDP ports for data transmission or only allowing reading specific CAN bus signals. This permission set is used to avoid security risks caused by over-granting permissions.

[0052] Specifically, during the Android system development phase, a custom SELinux policy file is created. This file declares the domain type of the security monitoring component process and assigns it precise access permissions. For example, it defines the vehicle signal interface device node paths that the process is allowed to access, restricting it to binding only to network sockets on specified ports. The policy file is compiled into a binary policy module, which is then integrated into the Android operating system's boot image. This policy module is loaded during system startup, ensuring that the security monitoring component process runs within a controlled permission environment.

[0053] Traditional development models typically deploy on the Android platform using default system permission configurations, which can lead to security monitoring components having permissions beyond their actual needs. For example, default access to all network interfaces or all vehicle bus signals might be allowed, creating a potential attack surface. This application, however, uses fine-grained permission control to retain only necessary permissions, reducing the risk of security vulnerabilities at the access control level.

[0054] Through the above technical solution, this application solves the permission compliance problem when deploying security monitoring components on the Android platform. It achieves minimum permission configuration through a mandatory access control mechanism, avoids system security risks caused by excessive permissions, and meets the dual regulatory requirements of vehicle systems for functional safety and information security.

[0055] Reference Figure 4 and Figure 5 As shown below, the design method described above will be illustrated with a specific example. The embodiment proposes a hybrid development model that combines automatic model generation with handwritten interface adaptation. This hybrid development model divides the entire system into a platform-independent core algorithm layer and a platform-related interface adaptation layer.

[0056] The first aspect of this embodiment is the development of a core algorithm layer for automatic model generation. This part is responsible for implementing the essential logic of all security monitoring rules. The specific process is as follows: First, a graphical modeling approach is adopted, specifically using Matlab / Simulink tools to construct the logical model of the security monitoring rules in a graphical manner. This model employs a layered architecture, including an INP input processing module (responsible for signal filtering and standardization), a Scheduler control module (responsible for timed trigger calculations), an SMT core rule logic calculation module (responsible for implementing multiple monitoring rules), and an OUTP output integration module (responsible for summarizing results).

[0057] Secondly, using code generation tools (such as Simulink Coder), the simulation-verified model is automatically converted into high-quality C++ source code. This code is entirely generated by the tool, independent of specific operating platforms such as Android or Linux, and contains only pure algorithmic logic.

[0058] The second aspect of the embodiment is the development interface adaptation layer, which is responsible for solving the interaction problem with the specific platform (CSC-Android), including: The specific steps for configuring the signal interface module are as follows: write code to implement interaction with the vehicle middleware SDK, acquire the required vehicle signals (such as CAN and SOA signals) in real time, convert and package these raw signals, and provide them to the core algorithm layer as input.

[0059] The configuration management module involves manually writing code to parse external configuration files, dynamically loading settings such as function switches and parameter thresholds, and passing them to the core algorithm layer. This enables flexible configuration for different vehicle models without requiring modification of the model or code generation.

[0060] The specific steps for configuring the communication output module are as follows: Write code to call the entry function of the core algorithm layer, drive it to perform calculations, and obtain the results. Then, encapsulate the results into a specific format and send them to other data collection components via a handwritten network communication program (such as UDPSocket).

[0061] The third aspect of this embodiment is system deployment and integration. To address the issue of deploying hybrid-mode outputs in the Android environment, this invention adopts the following deployment scheme: Cross-platform compilation is used to achieve this, specifically by using the cross-compilation toolchain provided by the Android NDK (Native Development Kit) to compile all C++ source code (handwritten interface + model generation code) into a native binary executable file that can run on automotive-grade chips (such as Qualcomm 8295).

[0062] The system-level integration step involves integrating the generated binary files, configuration files, etc., into the system image partition of the Android operating system, enabling the components to run as background resident processes and achieve automatic startup upon boot.

[0063] The security permission configuration steps involve customizing SELinux policy files to grant component processes the minimum set of permissions required to access the network, vehicle signals, etc., ensuring that they meet both functional requirements and comply with Android system security specifications.

[0064] The fourth aspect of the embodiment is overall collaborative operation. The platform-related handwriting interface adaptation layer acts like an adapter, converting the input / output of the CSC-Android platform into a standard format that the core algorithm layer can understand. The platform-independent model generation core algorithm layer acts like a brain, focusing only on calculation and judgment. The two exchange and call data through clearly defined function interfaces to jointly ensure the stable operation of the function.

[0065] This invention achieves efficient development and highly reliable code through model-based automatic generation in the first aspect; it achieves perfect adaptation to the Android environment through streamlined and efficient hand-written code in the second aspect and an NDK deployment scheme in the third aspect, jointly ensuring the reliable real-time operation of the functions. This is achieved by breaking down the scheme into two parts: platform-independent rules and platform-specific interfaces. The core algorithm is reusable, and the hand-written interfaces and deployment parts only require secondary development for new platforms, thus achieving platformization.

[0066] Reference Figure 5 As shown, taking the implementation of longitudinal following distance too close detection rules as an example, the specific implementation includes a model building part, a handwritten adaptation part, and a deployment part. The model building part (which is reusable) includes: establishing a rule calculation model in Simulink, with inputs including the vehicle speed, the distance to the vehicle in front, the driver's state, etc., and using an algorithm model to calculate the safe distance internally, and the output being a flag indicating whether the rule is triggered.

[0067] The handwritten adaptation part includes: (1) The handwritten code obtains the raw signal from the vehicle SDK in the Android system. (2) The handwritten code reads the configuration file and determines whether the rule is enabled. (3) The handwritten code converts the raw signal and calls the algorithm function generated by the model to perform calculation. (4) The handwritten code sends the calculated trigger result out through Socket.

[0068] The deployment process includes: (1) compiling all the above C++ code into an ARM architecture binary file using the Android NDK. (2) integrating the binary file and configuration file into the specified directory of the Android system image. (3) writing an SE configuration policy that allows the process to access the UDP Socket and the required counterpart nodes.

[0069] Understandably, when developing new vehicle models, the Simulink model of this rule can be reused directly without any modification. The hand-written code and deployment only need to be adapted to the platform characteristics of the new vehicle model, significantly reducing workload. It proposes a hybrid software development model that automatically generates core algorithm code based on the model while using hand-written code to complete platform interface adaptation, to solve the problems of functional migration and platform development for automotive domain controllers. It decouples platform-independent complex business logic (rule algorithms) from platform-related low-level operations (signal I / O, communication, configuration, deployment), and implements each using the most suitable technology. It also provides a complete and feasible technical solution from model design, code generation, interface adaptation to integration into the Android system via NDK compilation.

[0070] This application further proposes a design system for a security monitoring component for an automotive domain controller, including a graphical modeling module, a code generation module, an interaction module, a cross-platform compilation module, and a system deployment module.

[0071] The graphical modeling module refers to the component that builds the logical model of security monitoring rules through model design tools. Specifically, it can be implemented using Matlab / Simulink tools. It is used to lay out modules such as signal filtering, scheduling control, and logic calculation in a layered architecture, thereby reducing the complexity of manual coding.

[0072] The code generation module is a component that converts the logical model into core algorithm code. Specifically, it can be implemented using the Embedded Coder tool, which reduces manual intervention and avoids logical errors by automatically generating code.

[0073] The interaction module refers to the component that enables vehicle signal acquisition and interaction with the core algorithm. Specifically, it can be implemented by developing adaptation layer code, such as calling the vehicle middleware SDK to obtain signal data and encapsulating it into the algorithm input format to solve cross-platform data compatibility issues.

[0074] Cross-platform compilation modules refer to components that generate executable programs for the Android environment. Specifically, they can be implemented using the GCC cross-compilation toolchain, which eliminates portability obstacles caused by differences in operating systems through a unified compilation process.

[0075] The system deployment module refers to the component that integrates the program into the Android system partition. Specifically, this can be achieved by modifying the system image partition configuration, so that the security monitoring component runs as a system service, ensuring real-time performance and permission compliance.

[0076] Specifically, the graphical modeling module uses a drag-and-drop interface to build a layered model of input processing, scheduling control, logic calculation, and output integration modules. The code generation module automatically converts the verified model into C / C++ core algorithm code. The interaction module develops adaptation layer code to implement vehicle signal acquisition, data format conversion, and algorithm invocation. The cross-platform compilation module compiles the core code and adaptation layer code into an Android executable program. Finally, the system deployment module embeds it into the system image partition to complete the service deployment.

[0077] Existing technologies rely on manual coding, resulting in poor platform portability and low development efficiency. This application reduces coding workload through graphical modeling and automated code generation, enables cross-platform code reuse through cross-compilation toolchains, and ensures permission compliance through system service deployment, thereby significantly shortening the migration cycle and improving code quality.

[0078] Through the above technical solution, this application solves the compatibility problem of traditional handwritten code mode in Android platform porting. By modular design and automated toolchain, the core algorithm and platform adaptation layer are decoupled, enabling the safety monitoring component to quickly adapt to different vehicle configurations while meeting Android system security specifications, forming a reusable platform-based development solution.

[0079] This application further proposes a graphical modeling module for using Matlab / Simulink tools to construct an input processing module for signal filtering and standardization, a scheduling control module for timed triggering calculations, a logic calculation module for implementing multiple monitoring rules, and an output integration module for summarizing results. The input processing module, scheduling control module, logic calculation module, and output integration module are laid out in a hierarchical architecture.

[0080] The input processing module is responsible for noise reduction and format unification of the raw vehicle signals. This can be implemented using Simulink's filter and data type conversion modules to eliminate signal noise and convert signals from different sources into a unified format. The scheduling and control module triggers computation tasks according to a preset cycle. This can be implemented using Simulink's timer and state flow modules to ensure the real-time performance of the monitoring logic. The logic calculation module is the core unit for executing safety rule judgments. This can be implemented using Simulink's logic operation and condition judgment modules to implement complex rules such as collision warnings and speeding detection. The output integration module aggregates the results of multiple logic calculations. This can be implemented using Simulink's signal merging and data packaging modules to generate standardized output data. The layered architecture layout arranges different functional modules vertically in the order of input processing, scheduling, computation, and output layers. This can be achieved through Simulink subsystem partitioning and interface definition to reduce coupling between modules and improve maintainability.

[0081] Specifically, in building the safety monitoring system, the first step is to create an input processing module using Matlab / Simulink tools. For example, a Butterworth filter is used to smooth vehicle speed and acceleration signals, and a data normalization module converts CAN bus signals into floating-point values. Next, a scheduling and control module is built, for example, by setting a timer trigger with a 10ms cycle to drive subsequent modules to perform calculations. The logic calculation module implements multiple rules by combining AND gates, OR gates, and threshold comparators, such as triggering a warning when the vehicle speed exceeds 120km / h and the distance to the vehicle in front is less than 50 meters. The output integration module encapsulates the calculation results of each rule into a JSON format data packet. These modules are organized using a layered architecture, where the input processing layer interfaces with the vehicle signal source, the scheduling layer independently controls the execution rhythm, the calculation layer focuses on business logic, and the output layer is responsible for cross-system communication. Data is transferred between layers through standardized interfaces.

[0082] This application further proposes a design system for a security monitoring component for an automotive domain controller. The interaction module includes a signal interface module, a configuration management module, and a communication output module. The signal interface module is used to write code to interact with the vehicle middleware SDK, acquire the required vehicle signals in real time, convert and package the vehicle signals, and provide them as input to the core algorithm layer. The core algorithm layer is an algorithm model based on the core algorithm code. The configuration management module is used to write code to parse external configuration files and dynamically load function switches and parameter threshold settings, which are then passed to the core algorithm layer to achieve configuration for different vehicle models. The communication output module is used to write code to call the entry function of the core algorithm layer and drive the core algorithm layer to perform calculations on the converted and packaged data files to obtain the output results of the data interaction.

[0083] The signal interface module is responsible for data communication with the vehicle middleware. It can be implemented using Java or C++ to interface with the vehicle middleware SDK API, converting raw vehicle signals into a standardized data format through signal conversion logic. This module shields the underlying communication differences, providing a unified input interface for the algorithm layer. The configuration management module dynamically loads external configurations. It can use an XML or JSON parser to parse configuration files and dynamically set function switches and threshold parameters through reflection. This module enables flexible switching of vehicle configurations, avoiding the maintenance costs of hard coding. The communication output module triggers algorithm execution and processes the results. It uses JNI technology to call the core algorithm entry function written in C / C++ and encapsulates the calculation results in Protobuf format using data serialization technology. This module enables cross-language calls and unified data format, ensuring reliable communication between systems.

[0084] Specifically, during Android platform development, the signal interface module acquires vehicle bus signals in real time, such as raw data like vehicle speed and steering angle, through the vehicle middleware SDK. This data, after normalization, is encapsulated into structured data packets containing timestamps and data types, and transmitted to the core algorithm layer. The configuration management module reads the vehicle configuration file from external storage, parses out the function activation status and parameter thresholds, such as the activation conditions and safe distance thresholds for collision warning, and passes them to the core algorithm layer via memory mapping. Upon receiving the data packets, the communication output module calls the algorithm layer's calculation entry point through predefined function pointers, triggering the rule engine to perform logical operations on the input data. Finally, the calculation results are encapsulated in a network transmission protocol format and sent to the external data collection component.

[0085] Specifically, the graphical modeling module can execute steps S100, S110, and S120 in the design method of the above embodiments; the code generation module can execute step S200 in the design method of the above embodiments; the interaction module can execute steps S300, S310, S320, and S330 in the design method of the above embodiments; the cross-platform compilation module can execute step S400 in the design method of the above embodiments; and the system deployment module can execute step S500 in the design method of the above embodiments.

[0086] Furthermore, embodiments of the present invention also provide an execution device, comprising: at least one processor; and a memory storing instructions, which, when executed by the at least one processor, execute the design method for a security monitoring component for an automotive domain controller as described above.

[0087] Taking the example of a processor and memory in an execution device being connected via a bus, memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the control processor, and these remote memories can be connected to the controller via a network.

[0088] The non-transient software program and instructions required to implement the design method of the above embodiments are stored in memory. When executed by a processor, the design method of the above embodiments is executed, for example, the method described above is executed. Figure 1 Method steps S100 to S400 Figure 2 The method steps S110 to S120, etc.

[0089] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] Since the actuator adopts all the technical solutions of the design method of the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0091] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A secure monitoring component design method for automotive domain controllers, characterized by, The design method comprises: using a modeling design tool to construct a logical model of safety monitoring rules in a graphical manner; using a code generation tool to automatically convert the logical model that has been verified by simulation into core algorithm code; developing a platform interface adaptation layer by writing code to obtain vehicle signals, load configurations, and interact with the core algorithm code; cross-compiling the core algorithm code and the code of the platform interface adaptation layer using a cross-compilation tool chain to generate a native binary program that can run in an Android environment; integrating the generated native binary program into the system image partition of the Android operating system to enable the safety monitoring component to run as a system service.

2. The method of claim 1, wherein the method is used for a safety monitor component design for an automotive domain controller, and wherein the method comprises: The use of a modeling design tool to construct a logical model of safety monitoring rules in a graphical manner comprises: using a Matlab / Simulink tool to construct an input processing module for signal filtering and standardization, a scheduling control module for timing trigger calculation, a logical calculation module for implementing multiple monitoring rules, and an output integration module for aggregating results; arranging the input processing module, the scheduling control module, the logical calculation module, and the output integration module in a layered architecture.

3. The safety monitoring component design method for automotive domain controller according to claim 1, wherein, The development of a platform interface adaptation layer by writing code to obtain vehicle signals, load configurations, and interact with the core algorithm code comprises: writing code to interact with the vehicle middleware SDK to obtain the required vehicle signals in real time; converting and packaging the vehicle signals and providing them as input to the core algorithm layer, which is an algorithm model based on the core algorithm code; writing code to call the entry function of the core algorithm layer and drive the core algorithm layer to calculate the converted and packaged data file to obtain the output result of data interaction.

4. The safety monitoring component design method for automotive domain controller according to claim 3, wherein, The development of a platform interface adaptation layer by writing code to obtain vehicle signals, load configurations, and interact with the core algorithm code further comprises: writing code to parse external configuration files and dynamically load the settings of function switches and parameter thresholds to the core algorithm layer to implement configuration for different vehicle models.

5. The safety monitoring component design method for automotive domain controller as claimed in claim 3, wherein, The design method further comprises: encapsulating the output result into a specific format and sending it to an external data collection component through a network communication program for communication with the external data collection component.

6. The safety monitoring component design method for automotive domain controller according to claim 1, wherein, The design method further comprises: granting the safety monitoring component process the minimum set of permissions required to access the network and vehicle signals by customizing the SELinux policy file to meet the safety specifications of the Android system.

7. A safety monitoring component design system for automotive domain controllers, characterized by, comprises: a graphical modeling module for using a modeling design tool to construct a logical model of safety monitoring rules in a graphical manner; a code generation module for using a code generation tool to automatically convert the logical model that has been verified by simulation into core algorithm code; an interaction module for developing a platform interface adaptation layer by writing code to obtain vehicle signals, load configurations, and interact with the core algorithm code; A cross-platform compiling module is configured to cross-compile the core algorithm code and the code of the platform interface adaptation layer using a cross-compilation tool chain to generate a native binary program that can run in an Android environment; A system deployment module is configured to integrate the generated native binary program into a system image partition of an Android operating system so that the safety monitoring component runs as a system service.

8. The safety monitoring component design system for an automotive domain controller according to claim 7, wherein: The graphical modeling module is configured to use a Matlab / Simulink tool to construct an input processing module for signal filtering and standardization, a scheduling control module for timing trigger calculation, a logic calculation module for implementing multiple monitoring rules, and an output integration module for aggregating results, and to arrange the input processing module, the scheduling control module, the logic calculation module, and the output integration module in a layered architecture.

9. The safety monitoring component design system for automotive domain controller according to claim 7, wherein, The interaction module includes a signal interface module, a configuration management module, and a communication output module; The signal interface module is configured to write code to interact with the vehicle middleware SDK, to obtain the required vehicle signals in real time, to convert and package the vehicle signals, and to provide the vehicle signals as input to a core algorithm layer that is an algorithm model based on the core algorithm code; The configuration management module is configured to write code to parse an external configuration file and to dynamically load settings of function switches and parameter thresholds, and to pass the settings to the core algorithm layer to implement configuration for different vehicle models; The communication output module is configured to write code to call an entry function of the core algorithm layer and to drive the core algorithm layer to calculate data files that have been converted and packaged to obtain output results of data interaction.

10. An execution device, characterized by comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, perform the safety monitoring component design method for an automotive domain controller according to any one of claims 1 to 6.

Images