AUTomotive Open System ARchitecture (AUTOSAR) is a global development partnership formed by automakers, suppliers, and other companies in the electronics, semiconductor, and software industries. The AUTOSAR standard aims to achieve software standardization, reusability, and interoperability. It provides a development platform that supports both current and next-generation automotive Electronic Control Units (ECUs): The AUTOSAR Classic Platform supports traditional embedded applications, such as powertrains, chassis, body, and interior electronics; The AUTOSAR Adaptive Platform supports new service-oriented applications, including autonomous driving, connected vehicles, over-the-air (OTA) updates, and other adaptive applications. AUTOSAR static analysis ensures model quality and compliance on Embedded Coder and TargetLink platforms. AUTOSAR enables interoperability between Classic AUTOSAR, Adaptive AUTOSAR, and non-AUTOSAR ECUs within a single vehicle.
Introduction to Static Analysis of Embedded Coder/TargetLink AUTOSAR Models
Over the past two decades, AUTOSAR has become one of the most important standards for developing Software Components (SWCs) in the automotive industry, as it facilitates the distributed development and deployment of SWCs across various ECUs. At the same time, Model-Based Development (MBD) has emerged as a standard development approach across many industries and organizations, including, of course, the automotive sector. In this context, it is necessary to mention the standard modeling frameworks commonly used in the automotive industry, such as Simulink, as well as code generation frameworks like TargetLink and Embedded Coder, which have integrated support for AUTOSAR on both Classic and Adaptive Platforms. Meanwhile, when considering model-based software development or general software development, it is essential to adopt comprehensive model static analysis methods to ensure the quality of the relevant software at both the model and code levels.
Furthermore, software safety itself is a fundamental requirement for automotive products. The development of automotive software must comply with relevant safety standards, such as ISO 26262 for safety-related automotive software development. Ensuring the quality of model-based software requires specialized quality assurance tools. For instance, the MES Model Examiner® (MXAM) from MES, which is widely used in industry, provides comprehensive and thorough static analysis for quality assurance. The short video “AUTOSAR-Compliant Modeling with MXAM” demonstrates how MXAM and AUTOSAR cooperate to achieve compliance. Following that, this article provides a more in-depth analysis.
How does MES Model Examiner® (MXAM) support static analysis of models?
First, a brief overview of the MXAM workflow is provided. The MXAM workflow mainly includes the following steps: creating a new project or opening an existing one, selecting the model and configuring the guideline document, executing the analysis, reviewing the analysis results, repairing guideline violations automatically or manually with guidance, justifying violations with annotations, and finally saving and exporting the compliance report. The detailed process is shown in Figure 1.
MXAM supports the verification of various model types: Simulink, dSPACE TargetLink, or ASCET. When creating or opening an MXAM model verification project, the currently active model in Simulink can be automatically detected through the Graphical User Interface (GUI), as shown in Figure 2. Additionally, in a continuous integration environment, the target model artifact can be specified by editing Windows or MATLAB scripts.
After loading the model artifacts, it is essential to consider which guidelines should be validated in the static model analysis method. In an MXAM project, guidelines are set and managed in the form of guideline documents. These guideline documents originate from modeling guidelines based on industry and corporate standards. The MES tools provide corresponding guideline-checking routines specifically developed for various guidelines. In a development project, that is functional safety related, the MES functional safety guidelines related to functional safety can be selected. If verifying model compliance with MISRA guidelines is necessary, the MISRA SLSF guideline document can be configured. Or if TargetLink is used as the code generator, the relevant guidelines from the dSPACE TargetLink modeling guidelines should be applied. In addition to the industry and corporate standard modeling guidelines provided by MXAM, it is advisable to choose, configure, or customize company- or department-specific guideline documents based on specific project requirements, as shown in Figure 3.
Furthermore, regarding the selection or customization of guidelines, MXAM provides an efficient guideline document creation assistant. This tool enables the rapid creation of specific guideline documents tailored to the modeling environment and project requirements, supporting management and reference at both the company and department levels, as illustrated in Figure 4.
Before running the analysis, further model configuration can be performed if necessary, such as setting the guidelines for the current project, as shown in Figure 5.
Similarly, when certain model components or elements are irrelevant to the software being analyzed, an ignore list can be added and configured to selectively exclude specific model elements from the analysis of a particular rule set, as shown in Figure 6.
Additionally, through appropriate parameter settings, as shown in Figure 7, the automated guideline-checking routines provided by MXAM can be more flexibly applied to meet the model checking requirements of customized parameters for specific projects.
After completing the guideline set and corresponding parameter configuration, a static analysis can be performed using the analysis button in the MXAM tool interface, the MXAM command in the Simulink window menu bar, or the model context menu. Even without launching the MXAM tool, static analysis of models or artifacts can be conducted in batch mode by running MATLAB scripts or Windows batch scripts. As shown in Figure 8, MXAM is highly intelligently integrated into MATLAB through both the GUI and script command line, enabling seamless interoperability between MXAM and MATLAB.
After the analysis is completed, an analysis report is generated, providing an overview along with a detailed description of each section. The report includes all compliance results and complete information regarding the analyzed models in the MXAM project based on the configured guideline set. For violations identified in the report, the MXAM automatic repair function can be used to automatically correct the model, ensuring that the created model complies with the guideline set and customized parameter settings, as shown in Figure 9.
In addition, MXAM provides annotation feature that seamlessly integrates with standard review processes, supporting model reviews and deviation acceptance mechanisms within the project, as shown in Figure 10.
Then, the report is saved and exported or rerun the analysis until a well-refined model is obtained. Finally, the report can be exported in the required format based on different needs, as shown in Figure 11.
Following the above workflow, MXAM can efficiently support the review and optimization of AUTOSAR models, particularly for large and complex Simulink/TargetLink AUTOSAR model systems. When Embedded Coder/TargetLink is used as the code generator, and how does MXAM support the AUTOSAR software model development process?
Firstly, SWC and Runnable serve as the foundation for building AUTOSAR models using subsystems. In Simulink, SWCs and Runnables are modeled as subsystems. When using TargetLink to develop an AUTOSAR model, Figure 12 provides an example. An AUTOSAR SWC consists of multiple subsystems and various interface configurations. Within a subsystem, the Runnable algorithm is defined, and a TargetLink Function module is added to configure the subsystem as an AUTOSAR Runnable. This is how TargetLink creates AUTOSAR Runnables. On the other hand, when using Embedded Coder, periodic and aperiodic AUTOSAR Runnables are typically modeled using atomic subsystems or function-call subsystems. This discussion primarily focuses on the use case where subsystems are employed to model AUTOSAR Runnables.
The AUTOSAR Dictionary establishes the connection between the model and AUTOSAR configurations. For TargetLink, AUTOSAR configurations are included in the standard TargetLink Data Dictionary. Simulink, on the other hand, supports a dedicated AUTOSAR Dictionary. Through the AUTOSAR Dictionary, users can configure and decompose SWC or Runnable elements, as well as define interface settings, application data types, and implementation data types.
Both code generators support a round-trip mechanism. This means that if an AUTOSAR description file (ARXML), such as an SWC description, is imported into the model, a framework model can be generated or the existing model can be updated. Conversely, after modifying an SWC Runnable model, the corresponding SWC description can be updated accordingly.
When developing models using Embedded Coder, performing static tests on automatically generated model parts can lead to significant time and resource waste. MXAM v10.0 has expanded the analysis parameters (see Figure 13). If this parameter is set to "True", MXAM will only analyze model elements within the runnable subsystems.
During the development of AUTOSAR models, engineers typically start model generation and framework construction using ARXML files. As a result, multiple hierarchical levels and additional files are automatically generated. However, the auto-generated portions of the model do not necessarily require static testing, as they must adhere to the predefined AUTOSAR structure. Conducting static tests on these fixed parts would consume unnecessary time and effort. The new global parameter enables engineers to analyze only the models and functions within AUTOSAR Runnables. This allows developers to focus model analysis on application-specific and modifiable parts, significantly improving efficiency and saving valuable time.
The above configuration method is a static approach, and a dynamic approach can also be used to search for relevant artifact objects and run the analysis. To achieve this, it is necessary to define common identifiers that characterize the links. This process is relatively straightforward, as it only requires searching for Runnable Function blocks, such as using the Simulink API. With this method, the relevant subsystems for analysis can be automatically identified, ensuring that only the elements corresponding to Runnable subsystems in the model are analyzed.
The previously discussed examples focused on how MXAM supports AUTOSAR modeling with TargetLink. The focus then shifts to how MXAM supports the development of SWC models using Embedded Coder.
In Embedded Coder, the system target file is set to autosar.tlc or autosar_adaptive.tlc to enable code generation for AUTOSAR use cases. This serves as an extension to the standard ERT system target file provided by Embedded Coder, as shown in Figure 14. Here, two options influence AUTOSAR code generation regarding the generation of SWC ARXML description files, enabling the AUTOSAR compiler abstraction macros – This allows the generated code to abstract 16-bit platform compiler instructions in a platform-independent manner. The last option support root-level matrix I/O by implementing matrices as one-dimensional arrays – This determines whether the software supports root-level matrix input and output by representing matrices as 1D arrays.
In most projects, maintaining consistent configurations for code generation options is essential. This requirement also applies to AUTOSAR code generation settings. MXAM ensures consistency by providing the check mes_cgec_9004, which verifies the uniformity of relevant code generation settings. The verification process works by using a dedicated automated check to examine an Excel list containing predefined values for all code generation options, particularly those related to AUTOSAR. The model’s settings are then compared to the predefined values in the Excel worksheet. If inconsistencies are detected, MXAM reports failed findings and you can apply automatic repair. The predefined attribute values for these options can be customized based on specific project requirements.
It is important to understand that MXAM supports the use of AUTOSAR blocks in the process of transitioning from application software models to code generation, particularly for lookup table routines in the AUTOSAR library. A closer look at the built-in AUTOSAR module library in Simulink, as shown in Figure 15, reveals that these specially encapsulated lookup table routine blocks for AUTOSAR primarily include curve lookup tables, curve pre-lookup tables, map lookup tables, and map pre-lookup tables. During code generation, these AUTOSAR routines replace the corresponding library blocks.
The attribute settings of blocks have a direct impact on AUTOSAR code generation. When examining the corresponding attributes of these blocks, as shown in Figure 16, it becomes clear that they are essentially standard lookup table library blocks with encapsulation and dialog interfaces. Additionally, the data types between the encapsulation and block parameters remain synchronized. MXAM fully supports the correct reading of relevant module attributes, ensuring complete support for the code generation process of Simulink’s AUTOSAR lookup table routine block set.
In the case of Embedded Coder, Simulink uses the data types described on the right side, which have a fixed mapping relationship with AUTOSAR platform types, as shown in Table 1.
Therefore, within the Embedded Coder code generation framework, MXAM does not need to distinguish between AUTOSAR and non-AUTOSAR models. This is particularly important for scenarios such as checking data type consistency. For example, in the MAB guideline check na_0002, Boolean signal ports must be fed by Boolean signals rather than numeric signals. Currently, this guideline has been integrated into MXAM as part of its standard guideline library. MXAM fully supports the data type mapping mechanism used in AUTOSAR code generation within Embedded Coder, as illustrated in Figure 17.
Within the TargetLink model framework, the TargetLink AUTOSAR block library is used for AUTOSAR code generation. As shown in Figure 18, the TargetLink AUTOSAR block library includes common interfaces, input/output ports and buses, TargetLink data storage blocks, TargetLink Runnable blocks, as well as SWC receiver and sender port blocks. Additionally, there are receiver and sender comSpec blocks, which facilitate simulation interaction with the Run-Time Environment (RTE). MXAM fully supports the use of TargetLink AUTOSAR block library components for Classic and Adaptive Platforms application development.
The AUTOSAR use case approach in TargetLink differs slightly from that in Embedded Coder. TargetLink allows code generation for both AUTOSAR and non-AUTOSAR use cases from the same model. This can be understood as all relevant module interfaces in the TargetLink AUTOSAR library containing two levels of configuration. For example, in the interface settings of input/output port blocks and data storage blocks, both standard output port interface settings and AUTOSAR-specific interface settings are included. Additionally, data configurations in these blocks also differ. For instance, in the AUTOSAR block settings shown in Figure 19, the developer has selected platform data types such as int16 and specified a fixed Least Significant Bit (LSB).
As shown in Figure 20, under the non-AUTOSAR settings tab, different data types and scaling factors are specified. In summary, TargetLink allows parallel specification of data for both AUTOSAR and non-AUTOSAR use cases. Naturally, the specified data may differ between these two configurations.
How does the static analysis tool MXAM handle these AUTOSAR blocks? In practice, MXAM automatically distinguishes between AUTOSAR and non-AUTOSAR use cases. Its analysis of block data settings or decisions for static analysis is based on the AUTOSAR code generation mode and the AUTOSAR settings of the analyzed block. As shown in Figure 21, the code generation mode in the TargetLink main dialog is set to Classic AUTOSAR.
As shown in Figure 22, the AUTOSAR mode settings for the corresponding block must be configured for AUTOSAR to ensure that MXAM applies the appropriate AUTOSAR settings. In other cases, the goal is to maintain consistency with standard code generation as much as possible. For standard use cases, MXAM automatically adopts the block data settings from the output port configuration.
Here, a simple example is introduced. For the na_0002 in the MXAM guideline library, the guideline requires that logical signals must not be connected to blocks that operate on numerical signals. For instance, consider the Product block shown in Figure 23. According to the guideline, the first port of this block must receive a numerical signal. However, since the source signal setting for the bus input block has been configured as a Boolean signal (as shown in Figure 23-26), it violates the guideline. The static analysis results obtained in MXAM may vary depending on the code generation mode type set in the model.
Then take a closer look at the relevant settings. In this case, a uint16 definition is used.
If the model is set to standard mode, while the corresponding signal provider port is configured as a Boolean type, this results in a violation of na_0002, as shown in Figure 27. By running a check with the static analysis tool MXAM, the report identifies this violation, indicating that the port should receive a numerical signal, whereas it has been incorrectly set to a Boolean value.
However, when the TargetLink main dialog window is set to AUTOSAR mode, as shown in Figure 28, this is not an issue, and the result is shown in Figure 29.
If the Embedded Coder code generation options are recalled, the TargetLink settings follow a similar approach. As shown in Figure 30, the code generation options for the Classic AUTOSAR Platform in TargetLink influence the RTE API call method. Therefore, it is especially important to verify the interface settings of relevant Runnables before TargetLink code generation.
In addition, real-world projects may have specific configuration requirements for code generation settings. The automated check routine in MXAM can verify the required preset values using the guideline mes_cgtl_9002 from the MXAM guideline library. Custom settings for relevant configuration parameters can be referenced in the Excel parameter table attachment, as described in the guideline, as shown in Figure 31. For Simulink/Embedded Coder, a similar parameter table can also be found.
To summarize the static analysis of AUTOSAR models, several key points can be highlighted. First, the application of static model analysis tools such as MXAM provides efficient support for the rapid analysis of both Adaptive and Classic AUTOSAR models. Second, whether working with a TargetLink AUTOSAR model or an Embedded Coder AUTOSAR model, MXAM fully supports the static analysis process from AUTOSAR models to code. For TargetLink, there are distinct AUTOSAR and non-AUTOSAR settings, where different blocks apply data settings directly based on the AUTOSAR configuration. If AUTOSAR code generation settings are already configured in the model, MXAM applies to the AUTOSAR settings; otherwise, the model defaults to standard settings. Finally, by configuring MXAM's built-in tool parameter table, it is possible to automate the verification and correction of project code generation options, ensuring compliance with predefined settings.
In conclusion, introducing the MXAM tool early in the model development process helps to identify and correct model errors at an early stage. For AUTOSAR models requiring special configurations, detecting configuration errors early and automatically correcting them can significantly enhance development efficiency. Additionally, MXAM ensures that the model-to-code transition maintains high quality while complying with the ISO 26262 functional safety standard and its consistency requirements.
Use MXAM for AUTOSAR Models
Webinar: Static Model Analysis for AUTOSAR Models
Over the past 20 years, AUTOSAR has become one of the most important standards for developing software components in the automotive industry. In this webinar, we give you a practical demonstration of how the MES Model Examiner® (MXAM) can be used for AUTOSAR models in TargetLink/Embedded Coder to ensure quality in static model analysis.
