Due to the non-deterministic order of interactions between concurrent threads, testing of concurrent software is a challenge. In order to cope with this challenge, researchers have proposed analysis approaches in which the dynamic-based algorithms (e.g., Happens-before, Lockset) are an irreplaceable part. One of the biggest challenges of such algorithms, and a pre-condition to the analysis, is identification of memory locations that are shared between threads. This task is a significant contributor to the overhead of the analysis algorithms. In embedded systems that use static scheduling, scheduling is the implicit synchronization mechanism. In this paper, we suggest taking an advantage of static scheduling scheme to speed up the process of finding variables shared between threads, and with it, the identification of concurrency bugs. We demonstrate this concept by introducing modification to the Lockset algorithm and its internal structure. We show that considering static scheduling reduces the execution analysis time of the Lockset algorithm.

Embedded systems show a tendency of migrating to multicore processors. However, to fully use the potential of multicore processors, it is necessary to partition software into threads that execute concurrently and communicate using shared memory. In order to ensure the correctness and validity of shared data, threads need to synchronize their accesses. Currently prevailing lock-based synchronization introduces new challenges, as the hard-to-predict effect on the worst-case execution time seems to be most severe for embedded systems. Synchronization without locks (mainly lock-free) potentially offers many advantages over lock-based synchronization. In this paper, we investigate relevant aspects of embedded software systems affected by synchronization, including the testing process. We present conclusions in favor of and against migration to lock-free synchronization, including guidelines to help quantify the risks, and the results of applying testing tools to find concurrency bugs in software with lock-free synchronization. We look at the migration from the architectural point of view.

One of the first tasks in engineering embedded systems is the selection of the hardware; more specifically, the MicroController Units (MCUs). This selection is driven by business, technical, organizational, and legal constraints. Often, the hardware is delivered together with proprietary environments in which the software to be deployed has to be developed. This imposes architecturally significant constraints that are usually communicated inappropriately (in terms of time and format) to the engineering team. Examples are the usage of proprietary data types and programming language constructs (e.g., macros in C) and limitations to the reuse of existing software assets. To overcome this challenge, we propose an approach that has two main constituents: (i) the Embedded System Checklist, which aims at guiding the selection of MCUs according to the architecture constraints; and (ii) the Embedded System ESDT Dependency (SED) Architecture View, which connects the software design view with the technical view, describing hardware-related development environment limitations and their influences on the software architecture. We evaluated the application of these concepts in two industrial projects and show that making these dependencies transparent saves a lot of effort during software system development.

Concurrent software based on a shared-memory model is predominant in industrial applications that cannot afford to execute complex message-passing libraries. However, direct access to shared memory creates implicit dependencies between concurrently executing components. Therefore, the development and maintenance of such software is hard. In this paper, we argue the need to manage, at the architectural level, the implicitly high coupling between concurrent components that share memory. We suggest an approach that verifies architectural specifications against the implementation and finds potential mismatches. While static analysis approaches can be complete and verify all possible mismatches, they are often imprecise, leading to a large number of false warnings, especially in concurrent software. Instead, we built our approach, using dynamic analysis, on top of one of the most well-known algorithms for detecting data races, Eraser Lockset, and extended its model to support features required for the verification process. Since Lockset operates on the execution traces, test cases that produce these traces must ensure proper coverage. Therefore, we argue the need to use test cases conforming to the strict modified condi-tion/decision coverage criteria (MC/DC). Our version of Lockset takes advantage of the fact that possible shared memory locations are known in advance. We further improved its precision by considering atomic operations as a synchronization mechanism. The approach was evaluated on industrial AUTOSAR drivers that execute concurrently.

Traditional software testing methods are inefficient in cases where data inputs alone do not determine the outcome of a program's execution. In order to verify such software, testing is often complemented by analysis of the execution trace. For monitoring the execution trace, most approaches today insert additional instructions at the binary level, making the monitoring intrusive. Binary instrumentation operate on a low level, making it difficult to properly modify a program's states and to quantify its code coverage. In this paper, we present a framework for testing complex embedded multithreaded software on the logical level. Testing software on this level avoids dependency on concrete compilers and relates the execution to the source code, thus enabling coverage. Our non-intrusive execution monitoring and control is implemented using the LLVM interpreter compiler infrastructure. Instead of forcing thread interleaving, we suggest simulating interleaving effects through non-intrusive changes of shared variables. This makes it possible to test a single thread without executing the full software stack, which is especially useful in situations where the full software stack is not available (e.g., pre-integration testing). We complement existing approaches with new features such as dynamic configuration of monitoring and execution rollback to the checkpoints. Our approach introduces acceptable overhead without any complex setup.