Enhancing RTE Generation and BSW Configuration Tools for Embedded Automotive Systems

Embedded systems have integrated into our daily lives and play a core role in all fields, including automotive, aerospace, healthcare, manufacturing, energy, and consumer electronics. Current high-end vehicles are equipped with over 90 electronic control units (ECUs), with software code approaching 1 GB, and these ECUs account for 25% of the cost of the vehicle, contributing 40% to 75% of the added value. In the automotive field, the trend of utilizing modern embedded systems to realize increasingly complex software functions, replacing traditional mechanical systems, has never ceased. Similarly, the demand for more complex software tools that support these systems and software development processes in a holistic manner is also growing. Therefore, addressing the impending issues of modern real-time systems, also related to ISO 26262, model-based development (MBD) seems to be the best method to support the system descriptions being developed in a more structured way. The model-based development approach provides different views and different levels of abstraction for different stakeholders, and offers a central storage of information. This improves the consistency, correctness, and completeness of system specifications. However, seamless integration of this model-based development is still the exception rather than the rule, and MBD approaches often fail to meet requirements due to a lack of integration at the conceptual and tool levels.

The purpose of this paper is to propose a tool approach that can seamlessly describe safety-critical software, from system-level requirements to software component implementation, in both directions. Using the provided tools, basic software (BSW) component configurations can be generated using hardware-software interface (HSI) information, as well as automatically generating the runtime environment layer (RTE; the interface between application software (ASW) and basic software).

The tool consists of a basic software configuration generator and a software interface generator, the latter generating .c and .h files for linking ASW and BSW. To ensure the versatility of the tool, the required HSI information can be imported from HSI spreadsheet templates or system model representations. On one hand, the goal is to support consistent and traceable improvements from the early conceptual phase to software implementation; on the other hand, it combines the versatility and intuitiveness of spreadsheet tools (such as Excel) with the properties of MDB tools (such as different views, levels of abstraction, central information sources, and information reuse) to support semi-automated generation of BSW configurations and the SW-SW interface layer (known as runtime environment – RTE in AUTOSAR).

The document is organized as follows:

Section 2 provides an overview of related work and the model-based development toolchain on which this approach is based. Section 3 provides a description of the proposed tool and a detailed explanation of the contributions. Section 4 introduces the application and evaluation of the method. Finally, Section 5 summarizes the work and outlines the proposed method.

The development of automotive embedded software and the configuration of underlying basic software and embedded systems are engineering fields and research topics aimed at transferring the development process to automated workflows to improve consistency and address the complexities of software development processes across areas of expertise and domain boundaries.

With the increasing complexity of software over the past few years, managing the automotive embedded software development process has become increasingly necessary. To address this complexity, the AUTOSAR alliance was established, and the AUTOSAR methodology provides standardized and well-defined interfaces between different software components. The AUTOSAR methodology has three different implementation classes (ICC – Implementation Consistency Class). The main advantage of the AUTOSAR ICC1 method compared to the complete AUTOSAR methodology (ICC3) is clearly time savings, as there is no need to familiarize oneself with the typically very complex and time-consuming AUTOSAR tools. The ICC1 method does not leverage the full toolchain support of AUTOSAR for RTE configuration and communication interface advantages, but instead leverages standardized component interfaces to exchange data between ASW and BSW, thus having the characteristic of separating application-specific and hardware-specific software parts (such as native non-AUTOSAR development). ICC1 primarily focuses on SW engineering, more specifically on integrating ASW into a given SW architecture. However, aspects related to control system engineering (including HW/SW co-design) are not integrated and must be manually executed for aspects such as HW/SW interface definition, as shown in Figure 1. The tool approach presented in this paper enhances this aspect by providing a framework for visualizing ASW and BSW interface configurations and automatically generating the corresponding .c and .h files (see Figure 2). Additionally, available hardware-software interface (HSI) information can be utilized to generate basic software (BSW) component configurations, and the HSI information import functionality can also handle HSI spreadsheet templates to ensure the versatility of the tool.

In summary, many of the studied methods do not support (1) source code generation and (2) configuring basic software from information available at the system level and system models. In contrast, our proposed method not only supports the automatic generation of RTE source code but also supports the automatic generation of embedded system’s basic software configuration from system models.

The basic concept of the method is to have a consistent information repository as a central information source, storing all information related to all engineering disciplines involved in the development of embedded automotive systems in a structured way. This concept focuses on allowing different engineers to complete their work in their specific ways while providing tracking and dependency analysis regarding the entire system’s functionality (e.g., functional safety, cybersecurity, or reliability). The method is derived from common AUTOSAR-based approaches and also supports non-AUTOSAR or AUTOSAR ICC1 methods, which are often hindered by a lack of supporting tools. The decision not to adopt the full AUTOSAR methodology is based on the need to focus not only on AUTOSAR-based automotive software development but also on the complexity of the AUTOSAR standard, as not all development tools fully support the entire standard, leading to some incompatibility and interoperability issues.

Figure 2 provides an overview of the method and highlights the main contributions.

The tool approach presented in this paper provides a framework for visualizing ASW and BSW interface configurations and automatically generating the corresponding .c and .h files (see Figure 2). Additionally, available hardware-software interface (HSI) information can be utilized to generate basic software (BSW) component configurations, and the HSI information import functionality can also handle HSI spreadsheet templates to ensure the versatility of the tool. More specifically, the contributions proposed in this work include the following parts:

• AUTOSAR-aligned UML modeling framework:

Enhanced UML configuration files to define AUTOSAR-specific artifacts, more specifically, for defining component interfaces (based on the virtual function bus abstraction layer), see Figure 2 – HW and SW modeling framework.

• BSW and HW module modeling framework:

Enhanced UML configuration files to describe BSW components and HW components. To ensure consistency in specifications and implementations across the entire control system, see Figure 2 – HW and SW modeling framework.

• RTE generator:

Supports generating interface files (.c and .h) between application-specific and hardware-specific software functions, see Figure 2 – ASW/BSW interface generator.

• Basic software configuration generator:

Generates BSW configurations according to the specifications in HSI definitions, see Figure 2 – BSW configurator.

• Spreadsheet information importer:

Supports importing HSI definition information in spreadsheet format, see Figure 2 – Spreadsheet information importer.

This proposed method bridges the gap between system-level development and software-level development by supporting consistent information transfer between system engineering tools and software engineering tools. Additionally, the method minimizes redundant manual information exchange between tools and helps simplify the seamless safety argumentation of developing systems according to ISO 26262. The benefits of this development approach are particularly evident in re-design cycles, tool changes, and reworking of development artifacts with interdependent relationships.

The contributions proposed in this research are part of the proposed framework aimed at achieving software development in the automotive environment. The implementation of this method is based on a versatile C# class library (dll) and API command implementations to ensure tool and tool version independence from general UML modeling tools (such as Enterprise Architect or Artisan Studio) and other related tools (such as spreadsheet tools and software development frameworks). The following sections will describe in more detail the key contributions made in this method.

A. AUTOSAR-aligned UML Modeling Framework

The first part of the method is a specific UML modeling framework that enables software architecture design to be represented in AUTOSAR form as it would be in advanced system development tools (in this case, Enterprise Architect). The specific UML configuration files limit the possibilities of UML to the software architecture development requirements of safety-critical systems and allow software architecture design to be represented in AUTOSAR form within system development tools (Enterprise Architect). In addition to the AUTOSAR VFB abstraction layer, this configuration file allows for the clear definition of components, component interfaces, and connections between interfaces. This provides the possibility of defining software architecture and ensures the correct definition of communication between architectural artifacts, including interface specifications (e.g., upper limits, initial values, formulas). Therefore, the SW architecture representation in EA can be linked to the system development artifacts, and traceability to requirements can be easily established. This offers more benefits in terms of constraint checking, traceability of development decisions (e.g., safety file generation), reuse, and ensures versatility, also supporting AUTOSAR-aligned development. Figure 3 shows an example of the representation of software architecture artifacts and interface information in Enterprise Architect. From the description, it is evident that all artifacts required for modeling the SW architecture have been represented and inherit the required information in the form of tagged values.

B. BSW and HW Module Modeling Framework

The AUTOSAR architectural method ensures hardware-independent development of application software modules until the final stages of the development process, thereby enabling application software developers and basic software developers to work in parallel. The hardware configuration files of this method allow for a graphical representation of hardware resources (e.g., ADC, CAN), computational engines (cores), and connected peripheral devices interacting with software. Assigning special basic software (BSW) and hardware module representations to establish links to the underlying basic software and hardware layers. This allows for intuitive graphical establishment of software and hardware dependencies as well as hardware-software interfaces (HSIs), as required by ISO 26262. The software signals of the BSW module can be linked to HW port pins through dedicated mappings. First, this enables modeling and mapping of HW details and SW signals, see Figure 4; second, this mapping establishes traceable port pin configuration links. Thirdly, this HW dependency can be used for interconnecting scheduling and task assignment analysis tools to analyze and optimize resource utilization.

C. Runtime Environment Generator

The third part of the proposed method is the SW/SW interface generator. This dll-based tool generates .c and .h files based on modeled HSI artifacts, defining the SW/SW interfaces between application software signals and basic software signals. Additionally, this generation eliminates the need for manually generating SW/SW interfaces without sufficient syntax and semantic support, and ensures the repeatability and traceability of these configurations.

Figure 5 provides a conceptual overview of the generated files. The .c and .h files at the application software level are generated by model-based software engineering tools (e.g., Matlab/Simulink). The basic software-level files are typically provided by hardware vendors. The files referenced in the SW/SW interface layer are generated by our method.

The generated files are designed using a two-step approach.

The first step of the interface method (interface.c and interface.h) establishes the interface between ASW and BSW based on AUTOSAR RTE calls. The second step (AV LIL BSW a.c and AV LIL BSW a.h) maps these AUTOSAR RTE-based calls to the HW-specific implementations of the basic SW drivers. This ensures independence from the BSW driver implementations and still allows for the AUTOSAR ICC1 method when needed.

D. Basic Software Configuration Generator

The basic software configuration generator is also part of the dll-based tool, which generates BSW driver-specific *cfg.c files. These files configure the vendor-specific low-level drivers (basic software drivers) for hardware devices according to HSI specifications. The mapping of HSI specifications to low-level driver configurations is hardware-specific and low-level driver implementation-specific, requiring completion once for each hardware device and the supported low-level driver package.

E. HSI Spreadsheet Information Importer

HSI definitions require mutual knowledge between hardware and software domains, and are the result of collective workshops among hardware, software, and system experts, serving as a link between different development levels. If hardware and software development occur simultaneously and there are overlapping dependencies with asynchronous update intervals, evidence of consistency and correct implementation of HSI can be challenging. Therefore, this method allows for practical and intuitive design of HSI definitions in spreadsheet tools (Excel) and converts them into reusable and versionable representations in MDB tools (Enterprise Architect). The spreadsheet templates define the structure of data representation in a project-specific and customizable manner. On one hand, this enables practical and intuitive design of HSI definitions using spreadsheet tools, while its machine-readable and human-readable symbols ensure a cost- and time-saving alternative to typically complex specialized tools; on the other hand, it enables the generation of SW/SW interface files and BSW configurations without relying on a model-based development toolchain. Figure 6 depicts the project-independent template structure used to prepare HSI definition data.

Figure 6. Project-independent Template Structure Example for HSI Definitions

This section demonstrates the benefits of the introduced method for automotive embedded system development.

We use the automotive battery management system (BMS) as a use case to evaluate the method. This use case is illustrative material, reduced for internal training purposes, and is not intended to be exhaustive or representative of cutting-edge technology.

The definition of the software architecture is typically carried out by software system architects in software development tools (Matlab/Simulink). In our method, this work package is included in the system development tools (as shown in Figure 3). This does not hinder the work of software architects but also allows existing HSI mapping information to be linked to the SW architecture (as shown in Figure 4).

The use case consists of 10 ASW modules and 7 BSW modules, with 19 interface definitions between ASW and BSW, using 3 basic low-level HW functions (digital input/output, analog input/output, and PWM output). Table 1 provides a more complete overview of the use case.

With the definition of 19 HW/SW interfaces, each SW signal having 10 parameters, and each HW pin having 13 parameters, a total of 437 parameter configurations can be utilized in the HSI spreadsheet template or MDB tools for generating ASW/BSW interfaces and BSW configurations. This resulted in the file architecture shown in Figure 7. Using the method, 8 additional interface files were generated, containing 481 lines of code (LoC) in source code and 288 LoC in configurations.

In beginning AUTOSAR-consistent development or supporting non-AUTOSAR SW development, our method adopts a smooth first-step approach of ICC1 AUTOSAR and generates an interface layer (similar to AUTOSAR RTE) without relying on full AUTOSAR tool support. In safety-critical development, the proposed method supports traceability links between BSW configurations and HSI information, eliminating the need for manual rework of interface source code, which further overcomes the major drawbacks of the ICC1 AUTOSAR method.

One of the significant challenges in embedded automotive system development is ensuring consistency in design decisions, software implementations, and driver configurations, especially in the context of safety-related development. This work proposes a method for seamlessly describing safety-critical software, from system-level requirements to software component implementations, in a traceable manner. Therefore, the available hardware-software interface (HSI) information can be utilized to generate basic software (BSW) component configurations, as well as automatically generating the software interface layer (the interface between application software and basic software). Considering this goal, we propose a framework consisting of a basic software configuration generator and a software interface generator for generating .c and .h files for linking ASW and BSW, which can also be combined with spreadsheet-based HSI definitions. The main benefit of this enhancement is that consistency and traceability are improved from the initial design at the system level to single CPU driver configurations, while reducing tedious and error-prone manual work in the system development process. Further improvements of the method include advancements in the repeatability and traceability aspects of software development configurations (such as driver configurations and SW-SW interfaces).

The application of the proposed method has been demonstrated using the automotive BMS use case, which was intended for training purposes for students and engineers and does not represent exhaustive or commercially sensitive projects. While the authors do not claim completeness of the analysis (due to confidentiality issues), the benefits of the method have been evident.