An AUTOSAR architecture diagnosis code generation method, device and medium

Abstract

The application provides an AUTOSAR architecture diagnosis code generation method, device and medium, and belongs to the technical field of computers. The method comprises the following steps: obtaining a diagnosis database required for configuring an AUTOSAR diagnosis system, wherein the diagnosis database records a plurality of diagnosis units and a logical relationship diagram formed by the diagnosis units; generating a plurality of diagnosis registers corresponding to the plurality of diagnosis units by using a register module in a Simulink application layer model according to the logical relationship diagram; performing parameter configuration on the plurality of diagnosis registers to generate a diagnosis database configuration file; generating a diagnosis global manager in the Simulink application layer model and then performing parameter configuration to generate a diagnosis global configuration file; and integrating the diagnosis database configuration file and the diagnosis global configuration file to obtain an AUTOSAR architecture diagnosis code file corresponding to the AUTOSAR diagnosis system. The application can realize the AUTOSAR diagnosis function in a lightweight manner.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an AUTOSAR architecture diagnostic code generation method, device and medium. Background Technology

[0002] Model-based development within the AUTOSAR architecture utilizes diagnostic functions during the modeling process. This involves directly calling AUTOSAR's diagnostic event management and function suppression management modules at the application layer. This requires pre-configuring the diagnostic system based on the modeling needs. Typically, AUTOSAR tools are used to generate diagnostic code files; however, these tools are expensive, making them inaccessible to small and medium-sized enterprises. Summary of the Invention

[0003] The main objective of this application is to propose an AUTOSAR architecture diagnostic code generation method, device, and medium that can generate AUTOSAR architecture diagnostic code files through modeling without relying on AUTOSAR tools, thereby achieving AUTOSAR diagnostic functions in a lightweight manner.

[0004] To achieve the above objectives, one aspect of this application proposes an AUTOSAR architecture diagnostic code generation method, the method comprising:

[0005] Obtain the diagnostic database required for configuring the AUTOSAR diagnostic system. The diagnostic database records several diagnostic units and their logical relationship diagrams.

[0006] Based on the aforementioned logical relationship diagram, a registry module is used in the Simulink application layer model to generate several diagnostic registry units corresponding to the aforementioned diagnostic units;

[0007] Configure the parameters of the aforementioned diagnostic registrars to generate a diagnostic database configuration file;

[0008] A diagnostic global manager is generated in the Simulink application layer model. The diagnostic global manager is used to manage the behavior of the AUTOSAR diagnostic system. Then, the parameters of the diagnostic global manager are configured to generate a diagnostic global configuration file.

[0009] The diagnostic database configuration file and the diagnostic global configuration file are integrated to obtain the AUTOSAR architecture diagnostic code file corresponding to the AUTOSAR diagnostic system.

[0010] Furthermore, the step of configuring parameters for the plurality of diagnostic registrars to generate a diagnostic database configuration file includes:

[0011] The diagnostic registrars are classified to obtain multiple sets of diagnostic registrars;

[0012] For each set of diagnostic registrars, a first configuration structure corresponding to the set of diagnostic registrars is generated, and then the first configuration structure is assigned a value using the set of diagnostic registrars. Subsequently, the first configuration code file corresponding to the set of diagnostic registrars is generated using the assigned first configuration structure.

[0013] The diagnostic database configuration file is obtained by integrating the multiple first configuration code files corresponding to the multiple sets of diagnostic registrars.

[0014] Furthermore, assigning values ​​to the first configuration structure using the diagnostic registrar set includes:

[0015] For each diagnostic registry included in the diagnostic registry set, in response to a user's click operation on the diagnostic registry, the first configuration interface corresponding to the diagnostic registry is displayed;

[0016] The system receives configuration parameter values ​​related to the diagnostic registry input by the user on the first configuration interface, and assigns values ​​to the members of the first configuration structure associated with the diagnostic registry.

[0017] Furthermore, configuring the parameters of the diagnostic global manager to generate a diagnostic global configuration file includes:

[0018] In response to the user's click operation on the global diagnostic manager, the second configuration interface corresponding to the global diagnostic manager is displayed;

[0019] The system receives global attribute parameter values ​​related to the behavior of the AUTOSAR diagnostic system, which are input by the user on the second configuration interface, to generate the global diagnostic configuration file.

[0020] Furthermore, the method also includes:

[0021] The interaction between the Simulink application layer model and the underlying AUTOSAR software is constructed.

[0022] Furthermore, the construction of the interaction between the Simulink application layer model and the underlying AUTOSAR software includes:

[0023] In the Simulink application layer model, a callback module is used to configure the first standard interface, which is used to allow the underlying AUTOSAR software to call the functional services provided by the Simulink application layer model.

[0024] In the Simulink application layer model, a service module is used to configure a second standard interface, which allows the Simulink application layer model to call the basic AUTOSAR diagnostic services provided by the underlying AUTOSAR software.

[0025] Furthermore, the configuration of the first standard interface using a callback module in the Simulink application layer model includes:

[0026] Based on the preset AUTOSAR specification information, multiple API interfaces and the input parameter types and return parameter types of each API interface are determined, and each API interface is used as a first standard interface.

[0027] Based on the multiple API interfaces and the input parameter type and return parameter type of each API interface, a callback module is used in the Simulink application layer model to generate multiple callback triggers corresponding to the multiple API interfaces;

[0028] For each callback trigger corresponding to the API interface, a second configuration structure corresponding to the callback trigger is generated. Then, a function call subsystem connected to the callback trigger is configured in the Simulink application layer model. Subsequently, the model function is constructed using the connection relationship between the callback trigger and the function call subsystem, and the second configuration structure is assigned a value.

[0029] Furthermore, the configuration of the second standard interface using service modules in the Simulink application layer model includes:

[0030] Based on the preset AUTOSAR specification information, multiple AUTOSAR interfaces are determined, along with the input parameter type, return parameter type, and interface function name of each AUTOSAR interface. Each AUTOSAR interface is then used as a second standard interface.

[0031] Based on the multiple AUTOSAR interfaces and the input parameter type, return parameter type, and interface function name of each AUTOSAR interface, the Simulink application layer model uses a service module to generate multiple interface servers corresponding to the multiple AUTOSAR interfaces. Each interface server corresponding to the AUTOSAR interface is used to directly call the AUTOSAR standard service function.

[0032] To achieve the above objectives, another aspect of this application proposes an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0033] To achieve the above objectives, another aspect of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0034] This application includes at least the following beneficial effects: by generating several diagnostic registrars in the Simulink application layer model based on the diagnostic database required for configuring the AUTOSAR diagnostic system and using a registrar module, and by generating a diagnostic global manager in the Simulink application layer model to manage the behavior of the AUTOSAR diagnostic system, and further generating the AUTOSAR architecture diagnostic code file corresponding to the AUTOSAR diagnostic system by configuring the parameters of several diagnostic registrars and the diagnostic global manager, the AUTOSAR diagnostic function can be lightweightly implemented through modeling without relying on AUTOSAR tools. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating an AUTOSAR architecture diagnostic code generation method provided in an embodiment of this application;

[0036] Figure 2 This is a schematic diagram of the logical relationship formed by several diagnostic units provided in the embodiments of this application;

[0037] Figure 3 This is a schematic diagram of several diagnostic registrars provided in the embodiments of this application;

[0038] Figure 4 This is a schematic diagram illustrating the configuration effect of the extended data record registry provided in an embodiment of this application;

[0039] Figure 5 This is a schematic diagram illustrating the configuration effect of the data registry provided in an embodiment of this application;

[0040] Figure 6 This is a schematic diagram illustrating the configuration effect of the global diagnostic manager provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of at least eight callback triggers provided in the embodiments of this application;

[0042] Figure 8 This is a schematic diagram illustrating the configuration effect of the callback trigger corresponding to the Event Data Changed interface provided in this application embodiment;

[0043] Figure 9 This is a schematic diagram of at least four interface servers provided in an embodiment of this application;

[0044] Figure 10 This is a schematic diagram illustrating the configuration effect of the interface server corresponding to the Set Event Status interface provided in this application embodiment;

[0045] Figure 11 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of systems and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0047] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0048] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0050] Before providing a detailed description of the embodiments of this application, some of the nouns and terms used in the embodiments of this application will be explained first. The nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0051] AUTOSAR (Automotive Open System Architecture) is a collaborative development framework for automotive electronic systems, involving global automakers, parts suppliers, automotive research institutions, and automotive service providers. It aims to establish an open standard software architecture for automotive controllers, improving the reusability and interchangeability of software modules for various components.

[0052] Model-based development within the AUTOSAR architecture utilizes diagnostic functions during the modeling process. This involves directly calling the AUTOSAR Diagnostic Event Management (DEM) and Functional Inhibition Management (FiM) modules at the application layer. This requires pre-configuring the diagnostic system according to modeling needs. Typically, AUTOSAR tools are used to generate diagnostic code files; however, these tools are expensive, making them inaccessible to small and medium-sized enterprises. Furthermore, this approach suffers from the following drawbacks: the integration between AUTOSAR software and model code is relatively complex, resulting in inefficient configuration of the AUTOSAR diagnostic system; and the configuration method of AUTOSAR software is ill-suited to the rapid iteration and frequent modifications required by model-based development.

[0053] In view of this, embodiments of this application provide an AUTOSAR architecture diagnostic code generation method, device, and medium. This solution generates several diagnostic registrars in the Simulink application layer model based on the diagnostic database required for configuring the AUTOSAR diagnostic system and using a registrar module. It also generates a diagnostic global manager in the Simulink application layer model to manage the behavior of the AUTOSAR diagnostic system. Furthermore, by configuring the parameters of the several diagnostic registrars and the diagnostic global manager, the AUTOSAR architecture diagnostic code file corresponding to the AUTOSAR diagnostic system is generated. This enables lightweight implementation of AUTOSAR diagnostic functions through modeling without relying on AUTOSAR tools.

[0054] This application provides an AUTOSAR architecture diagnostic code generation method, which relates to the field of computer technology. It can be applied to terminals, servers, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the above-described AUTOSAR architecture diagnostic code generation method, but is not limited to these forms.

[0055] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0056] Figure 1 This is an optional flowchart illustrating an AUTOSAR architecture diagnostic code generation method provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105:

[0057] Step S101: Obtain the diagnostic database required for configuring the AUTOSAR diagnostic system. The diagnostic database records several diagnostic units and their logical relationship diagrams.

[0058] Step S102: Based on the logical relationship diagram, generate several diagnostic registers corresponding to several diagnostic units in the Simulink application layer model using the register module;

[0059] Step S103: Configure parameters for several diagnostic registrars to generate a diagnostic database configuration file;

[0060] Step S104: Generate a diagnostic global manager in the Simulink application layer model, and then configure the parameters of the diagnostic global manager to generate a diagnostic global configuration file.

[0061] Step S105: Integrate the diagnostic database configuration file and the diagnostic global configuration file to obtain the AUTOSAR architecture diagnostic code file corresponding to the AUTOSAR diagnostic system.

[0062] Steps S101 to S105 shown in the embodiments of this application can generate AUTOSAR architecture diagnostic code files by performing reasonable modeling in the Simulink application layer model without relying on AUTOSAR tools, thereby achieving AUTOSAR diagnostic functions in a lightweight manner.

[0063] In step S101 of some embodiments, the diagnostic database contains several diagnostic units including at least one component, at least one event, at least one function identifier (FID), at least one operating cycle, at least one diagnostic fault code (DTC), at least one freeze frame, at least one extended data, at least one extended data record, at least one data identifier (DID), and at least one data.

[0064] In step S101 of some embodiments, the logic diagram is mainly used to characterize the logical relationships between several diagnostic units, wherein the logical relationships between different types of diagnostic units include at least the following:

[0065] A component is associated with at least one event, and a connection is formed from that event to that component;

[0066] A Function Identifier (FID) is associated with a component or at least one event, and forms a connection line from the Function Identifier (FID) to the component, or forms a connection line from the Function Identifier (FID) to the event;

[0067] A diagnostic fault code (DTC) is associated with at least one event, and a connection line is formed from the event to the diagnostic fault code (DTC);

[0068] An event is associated with an operation cycle, and a connection line is formed from the event to the operation cycle;

[0069] A diagnostic fault code (DTC) is associated with an operating cycle, and a connection line is formed from the diagnostic fault code (DTC) to the operating cycle;

[0070] A diagnostic trouble code (DTC) is associated with at most one freeze frame and at most one extended data, that is, a diagnostic trouble code (DTC) is associated with one freeze frame, or a diagnostic trouble code (DTC) is associated with one extended data, or a diagnostic trouble code (DTC) is associated with both a freeze frame and an extended data, and forms a connection line from the diagnostic trouble code (DTC) to the freeze frame, and / or forms a connection line from the diagnostic trouble code (DTC) to the extended data;

[0071] A freeze frame is associated with at least one data identifier (DID), and a connection line is formed from the freeze frame to the data identifier (DID);

[0072] An extended data is associated with at least one extended data record, and a connection line is formed from the extended data to the extended data record;

[0073] A data identifier (DID) is associated with at least one piece of data, and a connection line is formed from the data identifier (DID) to the data.

[0074] An extended data record is associated with at least one piece of data, and forms a connection line from the extended data record to that data;

[0075] It should be noted that an operation cycle can be associated with an event and a Diagnostic Trouble Code (DTC) at the same time, and a piece of data can be associated with a Data Identifier (DID) and an Extended Data Record at the same time.

[0076] For example, when this AUTOSAR diagnostic system is applied in a vehicle tire diagnostic scenario, see [link to relevant documentation]. Figure 2 As shown, the diagnostic database contains several diagnostic units, including one component (representing the tire), two events (representing abnormal tire diameter and low tire pressure, respectively), one FID (representing tire function degradation), one operating cycle (representing the ignition cycle), one DTC (representing 0x407700), one freeze frame, one extended data, one extended data record (representing number 2), two DIDs (representing 0x1000 and 0x1001, respectively), and four data (representing tire pressure sensor measurement, temperature, DTC aging count, and event ID, respectively). The following focuses on... Figure 2 The logical relationships between some of the diagnostic units are explained below:

[0077] When a tire (a component) malfunctions, tire function degradation (FID) will be activated. Low tire pressure (an event) is only valid when the vehicle is in the ignition cycle (an operating cycle), and only then can 0x407700 (a DTC) be aged. When low tire pressure (an event) occurs, the fault information 0x407700 (a DTC) needs to be recorded, i.e., a freeze frame and extended data need to be recorded. The freeze frame represents the instantaneous information at the time of the fault, and the extended data represents supplementary fault information. The freeze frame contains 0x1000 (a DID) for recording tire pressure sensor measurements (data) and 0x1001 (a DID) for recording temperature (data). The extended data contains extended data records for recording DTC aging counts (data) and event IDs (data), and its number is 2.

[0078] In step S102 of some embodiments, a diagnostic registrar corresponding to each diagnostic unit is generated by using a registrar module in the Simulink application layer model. This registrar module is an S-function module in Simulink software, which can be understood as a custom function module with multiple built-in configuration parameters. The rules for generating code files from the S-function module are written by the user based on TLC (Target Language Compiler). The several diagnostic registrar generated for several diagnostic units include at least one component registrar, at least one event registrar, at least one FID registrar, at least one operation cycle registrar, at least one DTC registrar, at least one freeze frame registrar, at least one extended data registrar, at least one extended data record registrar, at least one DID registrar, and at least one data registrar. See [link to relevant documentation]. Figure 3 As shown.

[0079] In some embodiments, the implementation of step S102 may include, but is not limited to, the following: for every two diagnostic units that are associated as recorded in the logical relationship diagram, based on the directed connection line formed between the two diagnostic units, the diagnostic unit falling at the end of the directed connection line is designated as the first diagnostic unit, and the diagnostic unit falling at the beginning of the directed connection line is designated as the second diagnostic unit. In the Simulink application layer model, the registrar module first generates the first diagnostic registrar corresponding to the first diagnostic unit, then generates the second diagnostic registrar corresponding to the second diagnostic unit, and associates the first diagnostic registrar with the second diagnostic registrar.

[0080] For example, if the diagnostic database contains an extended data record and its three associated data, then in the Simulink application layer model, the registrar module first generates three data registrars corresponding to these three data respectively, then generates the extended data registrar corresponding to the extended data record, and associates the extended data registrar with the three data registrars.

[0081] It should be noted that this application does not require a specific generation order for multiple diagnostic registrars corresponding to multiple unrelated diagnostic units. For example, if a component is not associated with an operation cycle, the component registrar corresponding to that component can be generated first, followed by the operation cycle registrar corresponding to that operation cycle, or the operation cycle registrar corresponding to that operation cycle can be generated first, followed by the component registrar corresponding to that component. This application does not impose any limitations on this.

[0082] In some embodiments, the core of configuring the AUTOSAR diagnostic system lies in configuring the diagnostic database, and the above step S103 may include, but is not limited to, steps S201 to S203:

[0083] Step S201: Classify the diagnostic registrars corresponding to several diagnostic units to obtain multiple sets of diagnostic registrars.

[0084] In this step, all diagnostic registrars corresponding to all diagnostic units belonging to the same category are collected to form a diagnostic registrar set.

[0085] For example, when several diagnostic units contain one component and three events, and the content represented by these three events is different, a component registrar set is formed by the component registrar corresponding to the component, and an event registrar set is formed by the three event registrar corresponding to the three events.

[0086] Step S202: For each diagnostic registrar set, generate a first configuration structure corresponding to the diagnostic registrar set, then assign values ​​to the first configuration structure using the diagnostic registrar set, and finally use the assigned first configuration structure to generate the first configuration code file corresponding to the diagnostic registrar set.

[0087] In this step, when the number of diagnostic registrars in the diagnostic registrar set is N, a first configuration structure of length N is generated, and each diagnostic registrar in the diagnostic registrar set is a member of the first configuration structure. The index of each diagnostic registrar in the diagnostic registrar set in the first configuration structure is automatically generated in the form of a macro definition.

[0088] In this step, the first configuration structure is assigned values ​​using the diagnostic registry set. Specifically, for each diagnostic registry in the diagnostic registry set, in response to the user's click operation on the diagnostic registry, the first configuration interface corresponding to the diagnostic registry is displayed; the configuration parameter values ​​related to the diagnostic registry entered by the user on the first configuration interface are received, so as to assign values ​​to the members of the first configuration structure associated with the diagnostic registry.

[0089] For example, for any extended data record registrar included in the extended data record registrar set, see [link to documentation]. Figure 4 As shown, by double-clicking the extended data record register, the user can display the first configuration interface corresponding to the extended data record register. By entering relevant configuration parameter values ​​such as data record name, data record number and data source on the first configuration interface, the user can simultaneously assign values ​​to the members associated with the extended data record register contained in the first configuration structure corresponding to the extended data record register set.

[0090] It should be noted that, see Figure 4 It is understood that some members in the first configuration structure corresponding to the extended data record registry set do not appear on the first configuration interface corresponding to the extended data record registry, meaning they cannot be configured through the extended data record registry. These members will automatically adopt preset values ​​when the model generates code. Furthermore, this application allows the first configuration interface corresponding to the extended data record registry to select preset relevant configuration information from an external database, and also allows the deletion of some configuration parameter options on the first configuration interface corresponding to the extended data record registry to reduce the workload of user configuration, and also allows the addition of some configuration parameter options on the first configuration interface corresponding to the extended data record registry to increase the freedom of user configuration.

[0091] For example, for any data registrar in the data registrar set, since the data can be selected from the underlying AUTOSAR software or the Simulink application layer model, when the data is selected from the Simulink application layer model, in this specific case, the data registrar will need to set an input interface to obtain specific data from the Simulink application layer model. That is, the data registrar will additionally generate a function, and write the entry point of the function into the first configuration structure corresponding to the data registrar set. See [link to relevant documentation]. Figure 5 As shown.

[0092] Step S203: Integrate the multiple first configuration code files corresponding to multiple diagnostic registry sets to obtain the diagnostic database configuration file.

[0093] Steps S201 to S203 as shown in the embodiments of this application involve model development based on Simulink software, selecting the S-function module of the registry module to generate the relevant diagnostic registry, and then using the configuration interface provided by the relevant diagnostic registry to complete the structure assignment in order to further generate the code file. This can realize the orderly and reasonable construction of the diagnostic event management module in the AUTOSAR architecture.

[0094] In step S104 of some embodiments, the diagnostic global manager is mainly used to manage the behavior of the AUTOSAR diagnostic system and configure parameters of the diagnostic global manager to generate a diagnostic global configuration file. The corresponding implementation may include, but is not limited to, displaying a second configuration interface corresponding to the diagnostic global manager in response to the user's click operation on the diagnostic global manager; receiving global attribute parameter values ​​related to the behavior of the AUTOSAR diagnostic system input by the user on the second configuration interface to generate a diagnostic global configuration file.

[0095] Specifically, see Figure 6 As shown, by double-clicking the diagnostic global manager, the user can display the corresponding second configuration interface. By entering relevant global attribute parameters such as error counter increment step, error counter decrement step, error counter pass threshold, error counter failure threshold, maximum event storage quantity, and frozen frame record counting method on the second configuration interface, the diagnostic global configuration file will be automatically generated.

[0096] It should be noted that although the diagnostic global manager is presented in the form of a module, it essentially changes the Simulink model configuration parameters, that is, it maps the options in the Simulink model configuration parameters to the diagnostic global manager. This application allows the adjustment of the required global attribute parameter options on the second configuration interface corresponding to the diagnostic global manager.

[0097] By developing models using Simulink software, and after generating the diagnostic global manager, the configuration interface provided by it can be used to assign parameters to further generate code files, thus enabling the orderly and reasonable construction of the functional suppression management module in the AUTOSAR architecture.

[0098] In some embodiments, after configuring the AUTOSAR diagnostic system in the Simulink application layer model by executing steps S101 to S105, it is also necessary to establish the interaction relationship between the Simulink application layer model and the underlying AUTOSAR software so that the AUTOSAR diagnostic function can be fully implemented in the Simulink application layer model. Specifically, this is manifested as follows:

[0099] Firstly, a callback module is used in the Simulink application layer model to configure the first standard interface. This first standard interface is the interface for the underlying AUTOSAR software to access the Simulink application layer model. The code it calls belongs to the Simulink application layer model and is mainly used to allow the underlying AUTOSAR software to call the functional services provided by the Simulink application layer model.

[0100] For example, regarding the application scenario of this first standard interface: when the underlying AUTOSAR software detects a change in the status bit of UDS (Unified Diagnostic Services), it needs to notify the Simulink application layer model through this first standard interface so that it can call the corresponding control policy to handle this change.

[0101] Secondly, the Simulink application layer model uses a service module to configure the second standard interface. This second standard interface is the interface for the Simulink application layer model to access the underlying AUTOSAR software. The code it calls belongs to the underlying AUTOSAR software and is mainly used to allow the Simulink application layer model to call the basic AUTOSAR diagnostic services provided by the underlying AUTOSAR software.

[0102] For example, regarding the application scenario of this second standard interface: the Simulink application layer model can periodically report the test results of certain monitors to the underlying AUTOSAR software through this second standard interface.

[0103] In some embodiments, for configuring the first standard interface using a callback module in the Simulink application layer model, the corresponding implementation may include, but is not limited to, steps S301 to S303:

[0104] Step S301: Based on the preset AUTOSAR specification information, determine multiple API interfaces (Application Programming Interfaces) and the input parameter types and return parameter types of each API interface, and define each API interface as a first standard interface.

[0105] It should be noted that the input parameter types and return parameter types of each API interface are explicitly defined in C language in the AUTOSAR specification information.

[0106] Step S302: Based on multiple API interfaces and the input parameter type and return parameter type of each API interface, a callback module is used in the Simulink application layer model to generate multiple callback triggers corresponding to multiple API interfaces; wherein, the callback module is also an S-function module in Simulink software.

[0107] For example, in the existing AUTOSAR specification R23-11 version document, the specification section regarding the diagnostic event management module of the AUTOSAR architecture has defined at least eight API interfaces, see [link to relevant documentation]. Figure 7 As shown, the eight callback triggers corresponding to these eight API interfaces are generated using a callback module in this Simulink application layer model. The details are as follows:

[0108] The Clear Event Allowed interface takes no input parameters and returns parameters with both Allowed and StdRet types. The generated callback trigger is denoted as Clear Event Allowed Callback.

[0109] The Event Data Changed interface takes an input parameter of type Eventld and returns a parameter of type StdRet. The generated callback trigger is denoted as Event Data Changed Callback.

[0110] The Event UDS Status Changed interface takes OldStatus and NewStatus parameters as input parameters, returns a StdRet parameter, and generates a callback trigger denoted as Event UDS Status ChangedCallback.

[0111] The Monitor Status Changed interface takes an empty input parameter and returns a StdRet parameter. The generated callback trigger is denoted as Monitor Status Changed Callback.

[0112] The Init Monitor ForEvent interface takes an InitReason parameter as input and a StdRet parameter as return. The generated callback trigger is denoted as Init Monitor ForEvent Callback.

[0113] The Component Failed interface takes a Componentld parameter as input and a StdRet parameter as return. The generated callback trigger is denoted as Component Failed Callback.

[0114] The DTC Status Changed interface takes DTC, OldStatus and NewStatus as input parameters and returns a StdRet parameter. The generated callback trigger is denoted as DTC Status ChangedCallback.

[0115] The Clear DTC Notification interface takes DTC, DtcFormat, and DtcOrigin as input parameters and returns a StdRet parameter. The generated callback trigger is denoted as Clear DTCNotification Callback.

[0116] It should be noted that, under normal circumstances, for each API interface and its corresponding callback trigger, the input parameters of the API interface are actually the output ports of the callback trigger, enabling the underlying AUTOSAR software to pass the corresponding API parameters to the Simulink application layer model; the input ports of the callback trigger are actually the return results of the API interface, enabling the Simulink application layer model to return the corresponding function execution results to the underlying AUTOSAR software.

[0117] Step S303: For each API interface corresponding to a callback trigger, generate a second configuration structure corresponding to the callback trigger, then configure the function call subsystem connected to the callback trigger in the Simulink application layer model, and then use the connection relationship between the callback trigger and the function call subsystem to construct the model function, and assign values ​​to the second configuration structure; wherein, the function call subsystem is a module provided by the Simulink software, and the input and output parameters of the function call subsystem generally meet the usage requirements of the callback trigger connected to it.

[0118] For example, regarding the callback trigger corresponding to the Event Data Changed interface, see [link to relevant documentation]. Figure 8As shown, a function call subsystem connected to the callback trigger is configured in the Simulink application layer model. The function() port of the function call subsystem is connected to the Fcn port of the callback trigger, the Eventld port of the function call subsystem is connected to the Eventld port of the callback trigger, and the StdRet port of the function call subsystem is connected to the StdRet port of the callback trigger. These connections are used to construct the model function corresponding to the callback trigger. At the same time, the user double-clicks the callback trigger to display the third configuration interface corresponding to the callback trigger. Then, the user enters at least the function name on the third configuration interface to simultaneously assign values ​​to the second configuration structure.

[0119] Steps S301 to S303 as shown in the embodiments of this application involve model development based on Simulink software, selecting the callback module as an S-function module to generate relevant callback triggers, and then configuring the connection of the relevant callback triggers to the corresponding function call subsystem, which can realize the function call between the underlying AUTOSAR software and the Simulink application layer model.

[0120] In some embodiments, for configuring the second standard interface using a service module in the Simulink application layer model, the corresponding implementation may include, but is not limited to, steps S401 to S402:

[0121] Step S401: Based on the preset AUTOSAR specification information, determine multiple AUTOSAR interfaces and the input parameter type, return parameter type and interface function name of each AUTOSAR interface, and define each AUTOSAR interface as a second standard interface.

[0122] It should be noted that the input parameter types, return parameter types, and interface function names of each AUTOSAR interface are explicitly defined in terms of syntax and semantics within the AUTOSAR specification information.

[0123] Step S402: Based on multiple AUTOSAR interfaces and the input parameter type, return parameter type, and interface function name of each AUTOSAR interface, a service module is used in the Simulink application layer model to generate multiple interface servers corresponding to multiple AUTOSAR interfaces. The interface server corresponding to each AUTOSAR interface is used to directly call the AUTOSAR standard service function. The service module is also an S-function module in the Simulink software.

[0124] For example, in the existing AUTOSAR specification R23-11, the specification sections regarding the diagnostic event management module and function suppression management module of the AUTOSAR architecture have defined at least four AUTOSAR interfaces. These four AUTOSAR interfaces can meet most usage requirements. See [link to relevant documentation]. Figure 9 As shown, the four interface servers corresponding to the four AUTOSAR interfaces are generated using a callback module in this Simulink application layer model. The details are as follows:

[0125] The Set Event Status interface takes EventId and EventStatus as input parameters and returns StdRet as the return parameter. The interface function name is Dem_SetEventStatus, and the generated interface server is directly referred to as Set Event Status.

[0126] The Set Event Available interface takes EventId and Available parameters as input parameters and returns a StdRet parameter. The interface function name is Dem_SetEventAvailable, and the generated interface server is directly recorded as Set Event Available.

[0127] The Get Event UDS Status interface takes EventId as input and returns UdsStatus and StdRet parameters. The interface function is named Dem_GetEventUdsStatus and the generated interface server is directly referred to as Get Event UDS Status.

[0128] The Get Function Permission interface takes FID parameters as input parameters and returns Permission and StdRet parameters. The interface function name is FiM_GetFunctionPermission, and the generated interface server is directly recorded as Get Function Permission.

[0129] Among them, the Dem_SetEventStatus function, Dem_SetEventAvailable function, Dem_GetEventUdsStatus function, and FiM_GetFunctionPermission function should all belong to the AUTOSAR standard service functions.

[0130] It should be noted that, under normal circumstances, for each AUTOSAR interface corresponding to an interface server, the input port of the interface server is the input parameters of the AUTOSAR diagnostic basic service provided by the underlying AUTOSAR software, so that the Simulink application layer model transmits the corresponding AUTOSAR parameters to the underlying AUTOSAR software; the output port of the interface server is the return result of the AUTOSAR diagnostic basic service provided by the underlying AUTOSAR software, so that the underlying AUTOSAR software returns the execution result of the AUTOSAR diagnostic basic service to the Simulink application layer model.

[0131] For example, for the interface server corresponding to the Set Event Status interface, this interface server is used to directly call the Dem_SetEventStatus function. The Dem_SetEventStatus function has input parameter types including EventId parameter and EventStatus parameter, see [link to relevant documentation]. Figure 10 As shown, the EventStatus parameter of the Dem_SetEventStatus function corresponds to the input port of the interface server, and the return parameter of the Dem_SetEventStatus function corresponds to the output port of the interface server. Considering that the EventId parameter of the Dem_SetEventStatus function cannot be used as the input port of the interface server, the user double-clicks the interface server to display the fourth configuration interface corresponding to the interface server. The EventId parameter of the Dem_SetEventStatus function corresponds to the "Select Event" parameter item displayed on the fourth configuration interface. Because the EventId parameter is associated with the event, it needs to be associated with the event registrar in the form of a configuration interface.

[0132] Steps S401 to S402 shown in the embodiments of this application involve model development based on Simulink software, and the selection of the service module as an S-function module to generate the relevant interface server, which enables service calls between the underlying AUTOSAR software and the Simulink application layer model.

[0133] The AUTOSAR architecture diagnostic code generation method proposed in this application can lightweightly implement AUTOSAR diagnostic functions through modeling without relying on AUTOSAR tools. Furthermore, by integrating diagnostic configuration content, diagnostic function interfaces, and diagnostic service interfaces into the modeling process, effective integration between the underlying AUTOSAR software and the Simulink application layer model can be achieved. Moreover, the diagnostic configuration content, diagnostic function interfaces, and diagnostic service interfaces can be adaptively updated with frequently changing model versions to meet the rapid iteration requirements of model-based development, thereby improving development efficiency.

[0134] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described AUTOSAR architecture diagnostic code generation method. This electronic device includes any smart terminal such as a tablet computer or in-vehicle computer.

[0135] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0136] Please see Figure 11 , Figure 11 This illustrates the hardware structure of an electronic device according to another embodiment. The electronic device includes:

[0137] The processor 501 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0138] The memory 502 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 502 can store the operating system and other applications. When the technical solutions provided in the embodiments of this application are implemented through software or firmware, the relevant program code is stored in the memory 502 and is called and executed by the processor 501.

[0139] The input / output interface 503 is used to implement information input and output;

[0140] The communication interface 504 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0141] Bus 505 transmits information between various components of the device (e.g., processor 501, memory 502, input / output interface 503, and communication interface 504);

[0142] The processor 501, memory 502, input / output interface 503 and communication interface 504 are connected to each other within the device via bus 505.

[0143] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described AUTOSAR architecture diagnostic code generation method.

[0144] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0145] 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 processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0146] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0147] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0148] The system 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.

[0149] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0150] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0151] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0152] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

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

[0154] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0155] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Adopting this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0156] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for generating diagnostic codes for an AUTOSAR architecture, characterized in that, The method includes: Obtain the diagnostic database required for configuring the AUTOSAR diagnostic system. The diagnostic database records several diagnostic units and their logical relationship diagrams. Based on the aforementioned logical relationship diagram, a registry module is used in the Simulink application layer model to generate several diagnostic registry units corresponding to the aforementioned diagnostic units; Configure the parameters of the aforementioned diagnostic registrars to generate a diagnostic database configuration file; A diagnostic global manager is generated in the Simulink application layer model. The diagnostic global manager is used to manage the behavior of the AUTOSAR diagnostic system. Then, the parameters of the diagnostic global manager are configured to generate a diagnostic global configuration file. The diagnostic database configuration file and the diagnostic global configuration file are integrated to obtain the AUTOSAR architecture diagnostic code file corresponding to the AUTOSAR diagnostic system. The method further includes: Construct the interaction relationship between the Simulink application layer model and the underlying AUTOSAR software; The interaction between the Simulink application layer model and the underlying AUTOSAR software includes: In the Simulink application layer model, a callback module is used to configure the first standard interface, which is used to allow the underlying AUTOSAR software to call the functional services provided by the Simulink application layer model. In the Simulink application layer model, a service module is used to configure the second standard interface, which is used to allow the Simulink application layer model to call the AUTOSAR diagnostic basic services provided by the underlying AUTOSAR software. The configuration of the first standard interface using a callback module in the Simulink application layer model includes: Based on the preset AUTOSAR specification information, multiple API interfaces and the input parameter types and return parameter types of each API interface are determined, and each API interface is used as a first standard interface. Based on the multiple API interfaces and the input parameter type and return parameter type of each API interface, a callback module is used in the Simulink application layer model to generate multiple callback triggers corresponding to the multiple API interfaces; For each callback trigger corresponding to the API interface, a second configuration structure corresponding to the callback trigger is generated. Then, a function call subsystem connected to the callback trigger is configured in the Simulink application layer model. Subsequently, the model function is constructed using the connection relationship between the callback trigger and the function call subsystem, and the second configuration structure is assigned a value.

2. The AUTOSAR architecture diagnostic code generation method according to claim 1, characterized in that, The step of configuring parameters for the plurality of diagnostic registrars to generate a diagnostic database configuration file includes: The diagnostic registrars are classified to obtain multiple sets of diagnostic registrars; For each set of diagnostic registrars, a first configuration structure corresponding to the set of diagnostic registrars is generated, and then the first configuration structure is assigned a value using the set of diagnostic registrars. Subsequently, the first configuration code file corresponding to the set of diagnostic registrars is generated using the assigned first configuration structure. The diagnostic database configuration file is obtained by integrating the multiple first configuration code files corresponding to the multiple sets of diagnostic registrars.

3. The AUTOSAR architecture diagnostic code generation method according to claim 2, characterized in that, Assigning values ​​to the first configuration structure using the diagnostic registry set includes: For each diagnostic registry included in the diagnostic registry set, in response to a user's click operation on the diagnostic registry, the first configuration interface corresponding to the diagnostic registry is displayed; The system receives configuration parameter values ​​related to the diagnostic registry input by the user on the first configuration interface, and assigns values ​​to the members of the first configuration structure associated with the diagnostic registry.

4. The AUTOSAR architecture diagnostic code generation method according to claim 1, characterized in that, The step of configuring parameters for the diagnostic global manager to generate a diagnostic global configuration file includes: In response to the user's click operation on the global diagnostic manager, the second configuration interface corresponding to the global diagnostic manager is displayed; The system receives global attribute parameter values ​​related to the behavior of the AUTOSAR diagnostic system, which are input by the user on the second configuration interface, to generate the global diagnostic configuration file.

5. The AUTOSAR architecture diagnostic code generation method according to claim 1, characterized in that, The configuration of the second standard interface using a service module in the Simulink application layer model includes: Based on the preset AUTOSAR specification information, multiple AUTOSAR interfaces are determined, along with the input parameter type, return parameter type, and interface function name of each AUTOSAR interface. Each AUTOSAR interface is then used as a second standard interface. Based on the multiple AUTOSAR interfaces and the input parameter type, return parameter type, and interface function name of each AUTOSAR interface, the Simulink application layer model uses a service module to generate multiple interface servers corresponding to the multiple AUTOSAR interfaces. Each interface server corresponding to the AUTOSAR interface is used to directly call the AUTOSAR standard service function.

6. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 5.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images