Continuous Build Quality: Integration of Timing Validations
Today’s Continuous Integration (CI) and Build Pipelines can only partially ensure automated checks of non-functional requirements and properties. This means that a set of manual tests, which may be extensive, needs to be performed before each release. However, some of these non-functional tests can be automated using suitable tools and interfaces. This shortens integration cycles and reduces costs.
Vector offers a solution that enables standardized automation pipelines specifically for the automotive industry. To better embed this solution into existing processes and tool environments, Correct-By-Construction methods are developed, ensuring non-functional properties. Prototypes in the tool environments are implemented as part of the XANDAR project. The Vector products PREEvision https://www.vector.com/int/en/products/products-a-z/software/preevision/ and the TA Tool Suite https://www.vector.com/int/en/products/products-a-z/software/ta-tool-suite/ are applied in the project: the former serves as a modeling environment, and the latter as an analysis tool.
For example, when software applications are moved from one ECU to another, it has to be assured that the ECUs continue to function properly in the network, especially in terms of fulfilling timing requirements. To achieve early timing validations, the approach is to allocate initial load budgets in the logical architecture and to check for correctness and consistency as a first result. Later in the development process, when more details about the software and hardware are available, these checks provide more refined results. Multiple stages have been defined for these timing validations in the scope of the XANDAR project. They represent different modeling stages that occur during the development process, as shown in Figure 1.
Stage 1 represents the description of the logical architecture which still abstracts from software/hardware components. As described above, timing requirements and budgets can be checked for consistency and correctness. To simplify the transition to Stage 2, an initial hardware architecture can be modeled in Stage 1.5. It consists of computing nodes and communication channels which provide resources. Then, a first mapping between the logical and hardware architecture is determined. Logical components and their communication with each other consume the provided resources. At this point during the development, this resource information can be used to estimate utilization levels of hardware components. If necessary, the hardware architecture can be adjusted accordingly.
In Stage 2, the software architecture is derived from the logical architecture and modeled in the tool environment. The hardware architecture can be further detailed, e.g., individual processor cores can be specified. Based on these refinements, the software can also be mapped to the hardware. The additional information on hardware-specific resource requirements for individual software components is now available. Furthermore, communication protocols are defined enabling a more precise utilization analysis. For instance, this analysis calculates maximum communication delays and identifies timing requirements that cannot be fulfilled.
Stage 3 adds integration information to also take timing effects of resource sharing into account. To configure and analyze individual ECUs, the software developer uses additional tools to define and configure drivers, memory allocations, and operating systems. This configuration is supported by the DaVinci tools https://www.vector.com/int/en/products/products-a-z/software/davinci-configurator-classic.
After the applications have been configured with the drivers and operating system resources that are used, a detailed simulation of the ECU’s timing behavior can be performed in the TA Tool Suite. Here, it is possible to check whether the applications still fulfill their timing requirements when resource sharing effects are considered. As a result, a report on compliance with requirements and various other timing properties is provided. Such timing properties include the utilization of individual cores, the average response times of individual runnables, the maximum number of interrupts in a process, etc.
To automate the described design flow between stages 2 and 3, additional configuration information is needed. In XANDAR, it was identified that this information is provided, for the most part, by manual user interactions in the specific tools. Figure 2 shows the concept for information flow between the tools and steps of a CI Pipeline. Work products for which individual tools can make contributions in the context of DaVinci Team are indicated. PREEvision acts as a central starting point providing data for the individual CI steps.
As a starting point for the CI Pipeline, we assume that a basic configuration (Root Config) already exists. This RootConfig is generally provided in a distributed manner and contains hardware-specific information and definitions (e.g., clock frequencies of the cores, multipliers for bus clock frequencies, drivers, operating system, etc.). For instance, the source codes of the drivers originate from a git, while other libraries are stored as binary files in an Artifactory. The RootConfig is then supplemented with application-specific bus signals from the Communication Extract and synthesized empty OS Tasks. The latter can be derived automatically from the structure of the application software components (synthesize Tasks).
The individual application SWC Extracts are then imported and integrated in the integrateApplications step and are mapped to the source codes stored in a git. In the next step, all runnables from the software components are mapped to OS Tasks (mapRunnablesToTasks). After this step, the complete ECU configuration (Full Model) can be exported so that it can be analyzed and validated in the TA Tool Suite. If there are still problems in complying with time requirements, they are noted in a Timing Report. After the runnable-to-task mapping, the task source code (among others) is generated, and everything is compiled. The resulting Binary can be tested in further steps of the CI Pipeline (not shown in the figure) and integrated in the overall system.
The continuous consideration and validation of timing requirements and properties saves reworking costs that could arise in subsequent development steps or during the integration phase. Additionally, our tool flow concept enables a better automation of process steps that are still being performed manually today during the development of embedded systems. This results in a development process that is based on Correct-By-Construction & Continuous Integration as envisioned in the XANDAR project.
