The development of High Performance Computers (HPC) for Automated Driving or Driver Assistance causes new challenges for architects experienced in building systems based on AUTOSAR Classic Platform (CP). HPCs are typically built on an AUTOSAR Adaptive Platform (AP) or other middleware running on a Posix-based operating system. Ensuring reliability and predictability is exceptionally challenging. Some of the reasons are:

• Dynamic creation of processes and threads (no static OS configuration)
• Potentially less deterministic scheduling (e.g., Linux CFS)
• Service-Oriented Communication
• Heterogenous hardware with accelerators
• Limited bandwidth of the memory subsystem

This page will focus on the first very important point. To date, architects have struggled to model the execution behavior of dynamically created threads, but improvements to modeling tools are simplifying this challenge.

On AP, the life cycle of a process is controlled by the Functional Cluster Execution Management, including Startup and Restart. Once started, the processes’ main threads can create additional threads that can be executed on one of many cores of a multicore SoC.Some threads are created explicitly, while others are created implicitly. This is a significant change compared to the development of CP applications because there is no static OS configuration. As a result, architects must work closely with function developers to understand which explicit threads are defined. In addition to these, they must be aware that AP can also create implicit threads for the following:

• Callbacks for Service subscriptions
• Callbacks for Event subscriptions
• Method calls

The following example comes from a demonstrator built to highlight this challenge as part of INCHRON’s participation in the AUTOSAR  Working Group Resources. A callback, wgres_sensor, is started on a block of new incoming data. Since the data processing can be parallelized, wgres_sensor distributes the work across multiple workers from a thread pool. Once the workers are finished, the result is aggregated and passed to another thread, wgres_periodic. This passes the aggregated result to wgres_trigger that delivers the final result. The challenge for system architects is the lack of support for representing the behavior of multiple dynamically created worker threads in their modeling tools. This results in unsatisfactory workarounds being used, resulting in models lacking accuracy when compared to the actual software architecture.

To simplify the challenge for architects, chronSUITE includes native support for modeling threads and thread pools. When creating a model, functions that should run concurrently can be marked as such by using a simple concurrent flag during the definition of the model. This makes them execute in their own thread. All that remains is to define a thread join. This allows the system architect to specify the thread executions that must be waited for. Should the architect wish to experiment, the concurrent flag can be removed again, enabling rapid and straightforward sequential and parallel execution comparison.

chronSUITE also supports the use of event chains to model end-to-end processing times. Naturally, event chains can include the functions executed in the dynamically created threads of AP applications.

The model can now be simulated to examine event chain timing under various dynamic conditions. Our example shows that, on this occasion, the tight response time requirement can be fulfilled thanks to parallelizing the heavy processing undertaken in the threads.

System architects need more advanced capabilities in their modeling of HPCs to support the dynamic thread creation used in modern AP applications. Until now, this was only possible by using workarounds that often lacked accuracy. With chronSUITE, thanks to the newly introduced native support for threads and thread pools, architects can precisely identify timing-critical scheduling sequences and plan their deterministic execution. Thus, INCHRON’s modeling tools continue to adapt to support automotive development teams, allowing them to give timing the same level of focus as functional requirements.