Timing architecture patterns and anti-patterns

How can timing gaps be closed? A practical report

Authors: Karsten Schmidt, Audi Electronics Venture GmbH, Kai Richter, Symtavision GmbH

Contribution – Embedded Software Engineering Congress 2015

New technologies like multicore and Ethernet offer significantly greater computing and communication capacities than previously known. The available resources in the control units and the network must also be distributed among the numerous sub-functions to be integrated and their associated software. A well-designed timing architecture makes a crucial contribution to efficient implementation.

Introduction

New technologies like multicore and Ethernet offer significantly greater computing and communication capacities than previously known. They thus lay the foundation for implementing customer-centric megatrends in virtually all areas: driver assistance, electrification, connectivity, and autonomous driving. The new challenge lies in distributing the available resources in the electronic control units (ECUs) and the network across the multitude of sub-functions and their software to be integrated. A sound timing architecture makes a crucial contribution to efficient implementation. However, finding a suitable timing architecture is challenging, and those involved often lack experience in handling real-time requirements, as this task is not yet widely established.

In this article, we present best practices for solving recurring design problems related to timing, as well as successful and proven patterns for developing effective timing architectures. We explicitly distinguish these from non-patterns, worst practices, or not-so-good practices that are (unfortunately) still observed in practice today. Our aim is to provide suggestions on how and with what concrete steps the topic of timing could be better addressed in the future.

Situation of the automotive industry

Software plays an increasingly important role in realizing vehicle functionalities. While in early systems it was only found in selected components, it is now relevant for almost every vehicle function, resulting in a distinct software structure alongside the hardware. The vehicle's software elements are executed within electronic control units (ECUs) and other embedded components. Traditionally, in addition to non-functional requirements, the efficient use of scarce resources (memory, CPU cycles, communication slots) is a crucial aspect. Even the slightest increase in resource consumption directly impacts component costs. With the rising demands on functionalities and new value chains, the amount of software is now growing so rapidly that timing issues are frequently observed.

The developers are rising to the challenges and have already developed a variety of different strategies for managing timing problems. However, due to the complexity of the entire development process, typical problems keep recurring.

Understanding gap

Due to the division of tasks into system development, function development, and the actual software development, a communication problem between the different stakeholders in the development process is frequently observed. Each party is an excellent expert in their respective area, but relevant information is often lost in communication. This is exacerbated by the necessary protection of know-how when different companies collaborate. This fact is described in detail in [4, 5]. This effect is further amplified by the integration of different software components into a control unit.

Tool gap

Closely related to the understanding gap is the tool gap. Each stakeholder uses the tool best suited to their needs to efficiently solve their problems. Communication between the various parties is often characterized by manual processes.

Overall system understanding

Due to the collaboration across company boundaries and the integration of software from a wide variety of parties, it is difficult for the actual integrator to approach troubleshooting with an overall system understanding when problems arise.

Pattern

Fundamental and recurring experiences from a wide variety of projects manifest themselves in patterns that, when applied appropriately, offer significant benefits. Nevertheless, the application of patterns, or the avoidance of anti-patterns, requires a certain level of experience, as not every pattern is necessarily always successfully applicable.

Survey of the system

One pattern that, in our experience, is always applicable is the development of measurement methods for timing issues in the system under development, since only things that are quantitatively available can be optimized [1, 2].

The basic procedure for contact tracing is the recording of timestamps. In current systems, this typically takes place on two levels:

• Schedule: Tasks, Runnables, Start-Stop, Runtime, CPU Load
• Events: Sequences, intervals, offset, jitter, cycle time

This essentially concerns the executable code, which runs on the CPU and can therefore be traced. There are two basic methods for doing this:

• Code instrumentation
• Hardware tracing (typically through external devices)

It is important to note that, in principle, any measurement can distort the system. Therefore, it is necessary to design the measurement technology to be as non-intrusive as possible. In the future, CPU manufacturers will need to establish enhanced on-chip tracing capabilities (e.g., in a kind of timing unit for program memory accesses) to bring non-intrusive tracing from the laboratory to the vehicles.

System modeling

Develop a model of your system at the correct level of detail! A key foundation for this is a systematic collection of requirements. The following approach is recommended:

• At the code level, at least runtimes, cycle times and CPU load should be recorded.
• Deadlines must be recorded at the schedule level; otherwise, there are no criteria for schedule verification or optimization.
• At the level of end-to-end communication, at least requirements for the order of the runnables should be recorded.
• One practical recommendation is to annotate the timing-relevant data to the generated artifacts.

Compare system and measurement

This pattern uses and combines the two previous patterns. It is important that testable requirements exist, and that more complex timing requirements can be reduced to simple and testable timing requirements.

Using a timing simulation for forecasting

Simulations, particularly in the area of scheduling, which represents the original timing level, can be used to pre-estimate various problems. These include, in particular, "What if...?" types of questions, such as...

• Additional software components must/should be integrated.
• Changes in the mapping (e.g., moving software components to different time grids, especially for optimization)
• Robustness against runtime overruns of individual software components
• Rough estimate of the required increase in computing power

What is interesting about this pattern is that this step is easily implementable with systematic model capture.

Understanding the problem

Understand the problem and ask the right questions at the appropriate level of detail. To this end, the stakeholders involved in the project must be trained through suitable further education. During the training, it is particularly important to point out that there are different perspectives on timing (functional view, software, architecture, and schedule view) with sometimes differing terminology [3].

Furthermore, it is essential to establish timing experts within the company who can act as "interpreters" between differing perspectives in complex projects.

Training

Appropriate training is a crucial component of pattern development. It imparts the necessary knowledge, skills, and tools to apply the aforementioned successful patterns. Timing training should address the following questions:

• What is the "correct" granularity of the modeling?
• How can I measure my system?
• What do I need to pay attention to as an interpreter?
• Difference between concepts versus mechanisms
• Timing as a cross-cutting aspect and the need to work with different perspectives.

Keep it simple

This is a frequently underestimated pattern. A rule of thumb is: "Anything that can't be explained really quickly isn't simple." In our context, "really" means ensuring that an explanation is fully understood—that is, what it is and what it isn't. The authors are aware that vehicle systems are complex. Nevertheless, it must be noted that complexity is a problem in general, and that it's also worthwhile to build simpler systems.

It is also important to note that what might be a simple solution for one stakeholder could lead to extremely complicated solutions for other stakeholders.

Workflow and Tools

A well-designed workflow is essential. To meet the timing requirements, every workflow should include at least the following steps at the appropriate level of granularity.

• Tracing
• Target-actual comparison
• and the necessary requirements gathering at least at the schedule level

The following illustration (see PDF) demonstrates these steps using an exemplary product development process, taking timing characteristics into account.

Anti-pattern

Even though documenting anti-patterns may seem counterintuitive at first, they are very useful.

Even more process

Processes are not inherently bad. But processes need content and are subject to constraints that can differ in:

• Hardware ranging from 8-bit microcontrollers to embedded 32-bit systems and workstations with video acceleration.
• Functional languages (DSL)
• Supply chains

Processes for the sake of processes are academic exercises, but never real solutions. According to the authors, the individual existing process steps must be optimized through the targeted use of new and currently available technologies. This results in accepted standard building blocks with concrete benefits that can be combined as needed, depending on the project. Overly strict process specifications are restrictive and will therefore decrease acceptance. On the other hand, overly generic process descriptions offer no added value.

In addition, the process modules must be supported with appropriate training measures so that users can adapt the process steps to the specific situation.

Monster Tools

The most important aspect of this pattern is understanding that tools cannot perform magic. Once the problem is understood, tools, which are essentially machines that automate things, can be used very effectively. Furthermore, it's crucial to remember that tools should follow the process, not the other way around, with a tool dictating a specific workflow.

Summary

The complexity of the development process for highly integrated control units requires consideration of cross-cutting design packages, whereby in this paper we have focused on real-time capability and resource consumption.

It is important to understand that this is not an easy task, but rather a paradigm shift. No single tool or exchange format can close the process gap between system development, function development, and software development. Based on our own lived experience, we have presented fundamental, sequential patterns:

• Establishing systematic resource monitoring in software development as a fundamental starting point
• Use of model-based timing tools for demand forecasting and potential analysis, thereby reducing the gap "from below"„
• Expert moderation during requirements analysis and
• Training for employees who understand timing and resources as cross-cutting aspects and prepare the topic specifically for different perspectives, including the consideration of interfaces and transitions.

Simple, standard solutions currently exist only for a few special cases that can be identified and utilized by experts. We must systematically expand these solutions by implementing the aforementioned measures. By pursuing this systematically, the process gaps will be gradually minimized.

Bibliography

[1] K. Schmidt, J. Harnisch, D. Marx, A. Mayer, „Timing Analysis and Tracing Concepts for ECU Development,“ SAE Technical Paper 2014-01-0190, 2014, doi:10.4271/2014-01-0190.

[2] M. Jersak, K. Richter. H. Sarnowski, P. Gliwa, „The Right Timing Analysis Tools Increase Safety and Productivity“, ATZ Elektronik, 01/2009

[3] A. Hamann, D. Ziegenbein, S. Lampke, S. Schliecker, „Resource-Aware Control – Model-Based Co-Engineering of Control Algorithms and Real-Time Systems“, SAE World Congress, April 2015, Detroit, USA

[4] K. Schmidt, D. Marx, K. Richter, K. Reif, A. Schulze, T. Flämig, „On Timing Requirements and a Critical Gap between Function Development and ECU Integration“, SAE World Congress, April 2015, Detroit, USA

[5] K. Reif, K. Schmidt, F. Gesele, S. Reichelt, M. Saeger, N. Seidler, „Networked control systems in motor vehicles“ in ATZelektronik worldwide, 04/2008 Pages 18-23, Springer Fachmedien Wiesbaden GmbH (2008)

Download the article as a PDF file