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.