Curriculum for

Certified Professional for
Software Architecture (CPSA)^®
Advanced Level:
Module
EMBEDDED

Dependable Embedded Systems

Participants understand the systematic approach to systems development:

Participants can apply a systematic approach to modeling and analysis of functional architectures:

Participants understand that a functional architecture enables reasoning about system quality characteristics at an abstract level, e.g., regarding time behavior, dependability, or flexibility.

Participants know examples of how functional architectures can be modeled (e.g., with SysML or FAS [Weilkiens+2015]).

Participants understand the systematic approach to modeling and analysis of technical systems architectures:

Participants know examples of how technical system architectures can be modeled, for example with SysML.

Participants understand that the design of a technical systems architecture is an iterative process that requires feedback from software development and hardware development.

Participants know typical decisions that need to be made in the design of the technical systems architecture:

Participants understand the challenges of distributed systems regarding latency, throughput, lack of a global clock, and the impact on dependability.

Participants know different approaches for modeling software for embedded systems. They understand the basic concepts, strengths and weaknesses of these approaches:

Participants understand how models can be used for analyzing the software, for example regarding failures, schedulability, error propagation, and latency.

Participants are able to select a suitable modeling approach based on the requirements and boundary conditions of the system under development.

Participants understand how programming languages influence quality characteristics and cross-cutting concepts:

Participants know different programming language paradigms (e.g., procedural, object-oriented, functional). Participants know examples for programming languages supporting these paradigms that are suitable for embedded systems, and understand their strengths and weaknesses.

Participants understand how memory management strategies and memory-management-related capabilities of the programming language affect memory safety, flexibility, predictability, performance and programming complexity:

Participants know different language features and patterns for error handling and their strengths and weaknesses, such as return values, global error status variables, global error handlers, exceptions, monadic error handling (e.g., "Result" types, "Either" types).

Participants know how models can be used to generate artifacts for the realization, and understand the trade-offs:

Participants can explain and give examples for different error categories (e.g. memory-management errors, synchronization errors, type defects, timing errors, domain errors).

Participants understand how analysis techniques can be used to detect errors, and know the limitations of these techniques:

Participants know design principles and paradigms for embedded software, such as design by contract, the robustness principle, or defensive programming.

Understand the following terms and how these are related to each other: dependability, safety, availability, reliability, fault tolerance, security, fault, error, failure, redundancy, replication, freedom from interference, spatial interference, temporal interference, communication interference, fail operational, fail silent, fail stop, fail consistent.

Participants understand the fundamental approach for developing a safety-related system:

Participants understand that functional safety must be considered on the system level, and impacts systems architecture, software architecture, and hardware architecture.

Participants understand the influence of standards in the development of safety-related systems.

Participants understand the difference in approach to safety-related system development of standards such as the IEC 61508, ISO 26262, ISO 62304 and other domain-specific safety standards.

Participants understand the process of safety classification:

Participants understand that systems development, software development and hardware development are closely intertwined when developing dependable and safety-related systems. For example, software plays a critical role in diagnosing hardware failures, and hardware plays a critical role in ensuring freedom from interference between software units.

Participants understand fundamental concepts and activities for developing fault-tolerant systems and how they interact with each other:

Participants can apply architectural patterns and techniques for developing fault-tolerant and safety-related systems:

Participants understand that suitable processes and methods for design, implementation, verification, and testing are crucial to prevent faults in the system.

Participants know that in a safety-related system, norms and standards give recommendations for processes and methods.

Participants an select and apply patterns and techniques such as Checksum, Parameter Checking, Heartbeat, Leaky Bucket Counter, System Monitor, Watchdog, Plausibility Checks, Control-Flow Monitoring.

Participants can select and apply detection patterns that are used with redundancy such as Voting and Lockstep.

Participants understand the importance of timely error detection.

Participants can select and apply patterns for error recovery such as Data Reset, Error Handler, Failover, Retries, Limiting Retries, Quarantine, Deactivation, Restart, Return to Reference Point, Rollback, Roll-Forward.

Participants can select and apply patterns for error mitigation such as Error-Correcting Codes and Marked Data.

Participants understand that real-time requirements of embedded systems are the result of their interaction with the environment.

Participants can explain the difference between timeliness and speed.

Participants can explain the difference between hard/firm real-time requirements and soft real-time requirements.

Participants understand that all actions along the event chain from the occurrence of a relevant event to the system reaction must be examined when implementing real-time requirements (e.g., sensor data read-out, operating-system context switch, sensor-data processing, actuator control). For hard/firm real-time requirements, a deadline must be defined for each of these actions. Missing that deadline is not tolerable.

Participants understand the different types of events (periodic, sporadic, aperiodic).

Participants understand that real-time architectural design should be performed early on in the project.

Participants know that real-time architectural design may also encompass choosing and configuring an operating system, which poses a technological impact factor.

Participants understand the fundamental approach to developing real-time systems:

Participants know how real-time system design is integrated into the overall development life cycle.

Participants understand that extending functions or adding new functions at a later time can have a large impact on time behavior and schedulability. The degree to which such extensions must be supported is an important impact factor to real-time architectural design. They understand that real-time affects the entire life cycle of the system and influences many disciplines and activities (e.g., requirements elicitation, systems architecture, hardware architecture, software architecture, software implementation, test and verification, deployment).

Participants understand that real-time is a cross-cutting concern.

Participants are able to specify and model real-time requirements. They know different approaches to specifying real-time requirements (e.g., specifying real-time requirements in UML, SysML, or AADL) and can select a suitable approach for a particular system.

Participants can describe the time-triggered and event-triggered approaches to real-time architectural design. They understand the trade-offs of both approaches regarding determinism and flexibility.

Participants understand that the decision for an approach has a profound, cross-cutting impact on the architecture and the implementation and is therefore hard to change.

Participants can describe technical solutions like cyclic executive, RTOS-based event-triggered approach, and application-level interrupt handling.

Participants know criteria for deciding between different technical solutions. They are able to select a technical solution for a specific system and reasonably justify their decision.

Participants can describe how different technical solutions can be combined (e.g., cyclic executive and interrupts).

Participants understand approaches to handling non-periodic events (interrupt-driven execution, background execution, slack-stealing). They know further approaches (periodic, deferrable or sporadic server).

Cyclic schedules and frame-based scheduling:

RTOS-based event-triggered approach:

Application-level interrupt handling:

Participants understand the potential problems caused by concurrent access to shared resources (e.g., blocking time). They understand that whether these problems can actually occur depends strongly on the chosen technical solution to concurrency (e.g., time-triggered vs. event-triggered approach).

Participants understand solution approaches for interactions between jobs and their trade-offs (e.g., message passing, shared data).

Participants know strategies for preventing typical concurrency problems (e.g., critical sections, non-preemptive critical sections protocol, semaphores, synchronization objects and mutexes, atomic actions, non-blocking synchronization). They can select appropriate strategies for a specific system.

Participants know how to optimize critical sections (e.g., by assigning program elements which share the same software resources to the same RTOS task).

Participants understand how deadlocks occur and how they can be avoided.

Participants understand priority inversion and know solution approaches (priority ceiling, priority inheritance).

Participants can explain the characteristics of a real-time operating system. They understand that real-time operating systems and general-purpose operating systems serve different purposes.

Participants know a minimum of two examples of real-time operating systems and their characteristics.

Participants can refine the real-time architectural design in the context of the selected operating system (e.g., refine tasks priorities and assign program elements to task entities).

Participants know different approaches how the real-time architectural design can be evaluated, such as design reviews, performing schedulability analysis, or using tools for scheduling simulation and verification.

Schedulability analysis:

Worst-case execution time (WCET) analysis:

Shared resource analysis:

Participants understand that tools for specification, design and analysis of real-time systems are needed for complex embedded systems with many external real-time requirements.

Participants know application areas of tools for real-time architectural design and analysis, such as modeling the real-time architectural design, static WCET analysis, analytical schedulability analysis, white-box vs. black-box simulation of real-time systems. Participants know examples of specific tools and their application areas.

Participants understand the challenges introduced when building distributed or multi-core real-time systems (e.g., proper methods of synchronization, global scheduling, global time base, latencies imposed by communication).

Participants know different approaches to scheduling (partitioned, clustered, global scheduling) and migration in multicore systems (e.g., offline vs. online migration).

Participants understand the motivation and need for adaptability (supporting the evolution over time, variability in time) and variability (supporting multiple product variants, variability in space). They understand how the need for adaptability and variability can be determined and specified.

Participants know possible binding times when variability can be resolved (before runtime, at startup/load time, at runtime).

Participants know trade-offs and drawbacks of increased adaptability and variability as well as competing quality goals (e.g., testability, performance, safety, security, and backwards compatibility) and complementing quality goals (e.g., maintainability, reusability).

Participants know high level approaches to adaptability and variability such as the 150%-model, 80%-model, product platforms or product lines.

Participants understand that variability can occur at the functional level (e.g., product variants differ in the provided functions) and at the technical level (e.g., alternative technical solutions exist for the same functionality).

Participants understand how the separation between functional architectures and technical architectures can support adaptability and variability by allowing alternative technical architectures for the same functional architecture.

Participants know how to model variation points in requirements, functional architectures, and technical architectures.

Participants know how adaptability and variability are supported by:

Participants can apply these solutions to implement variation points in the architecture.

Participants understand that adaptability in embedded software is driven both by requirement changes and by evolution of the systems architecture. This evolution needs to be addressed in the software architecture and in the development process.

Participants understand the trade-offs of using legacy code and how its usage can restrict adaptability and variability.

Participants know how to maintain adaptability and deal with new adaptability requirements (e.g., by refactoring).

Participants know approaches how to handle system and software updates, as well as trade-offs of updates.

Participants know common tools to model and manage variability.

Participants understand how code generation can support adaptability and variability and know common tools for code generation.