diff --git a/docs/00b-basics/01-what-to-expect-of-this-module.adoc b/docs/00b-basics/01-what-to-expect-of-this-module.adoc index ecb23e1..93a75d6 100644 --- a/docs/00b-basics/01-what-to-expect-of-this-module.adoc +++ b/docs/00b-basics/01-what-to-expect-of-this-module.adoc @@ -24,7 +24,7 @@ achieved: The module “{curriculum-short}” conveys a methodical approach to architecture design for dependable embedded systems. It shows how software architecture interacts with the overall systems architecture, and how the requirements with -regards to safety, dependability, real time and adaptability are addressed in a +regards to safety, dependability, real-time and adaptability are addressed in a systematic way. In addition to patterns and solution concepts for designing appropriate software architectures, the module also addresses the analysis of software architectures with regard to the required quality characteristics. diff --git a/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc b/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc index 4c226ae..dab0f96 100644 --- a/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc +++ b/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc @@ -8,10 +8,10 @@ |=== | Content | Recommended minimum duration (minutes) -| 1. System development for embedded systems | 120 -| 2. Software development for embedded systems | 180 -| 3. Dependability and Functional safety | 330 -| 4. Real time and concurrency | 360 +| 1. Systems Development for Embedded Systems | 120 +| 2. Software Development for Embedded Systems | 180 +| 3. Dependability and Functional Safety | 330 +| 4. Real-Time and Concurrency | 360 | 5. Adaptability | 90 | | | Total | 1080 (18h) diff --git a/docs/01-system-development/00-structure.adoc b/docs/01-system-development/00-structure.adoc index 6bbaa1b..ba9556f 100644 --- a/docs/01-system-development/00-structure.adoc +++ b/docs/01-system-development/00-structure.adoc @@ -6,7 +6,7 @@ // end::DE[] // tag::EN[] -== System development for embedded systems +== Systems Development for Embedded Systems // end::EN[] diff --git a/docs/01-system-development/01-duration-terms.adoc b/docs/01-system-development/01-duration-terms.adoc index 08f7a48..158f92c 100644 --- a/docs/01-system-development/01-duration-terms.adoc +++ b/docs/01-system-development/01-duration-terms.adoc @@ -9,6 +9,6 @@ === Terms and Principles Systems architecture, functional architecture, technical systems architecture, -event chain, systems development, software development, hardware development. +event chain, systems development, software development, hardware development // end::EN[] diff --git a/docs/01-system-development/02-learning-goals.adoc b/docs/01-system-development/02-learning-goals.adoc index 3d98ae4..cbb50a2 100644 --- a/docs/01-system-development/02-learning-goals.adoc +++ b/docs/01-system-development/02-learning-goals.adoc @@ -47,11 +47,11 @@ functional architectures: * Model the system context with external systems, physical entities, users of the system and the logical events that occur between the system and its - environment + environment. * Hierarchically decompose the system from a purely functional perspective, identifying function blocks and their interactions via events or information - flows + flows. * Define event chains based on the functional architecture. An event chain traces the end-to-end behavior from an external triggering event to the @@ -62,44 +62,45 @@ 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 modelled, -e.g. with SysML or FAS <>.. +Participants know examples of how functional architectures can be modeled (e.g., +with SysML or FAS <>). [[LG-1-3]] -==== LG 1-3: Modeling and Analysis of Technical Systems Architectures +==== LG 1-3: Modeling and Analysis of Technical System Architectures Participants understand the systematic approach to modeling and analysis of technical systems architectures: * Analyze the impact factors, like quality requirements, organizational constraints, technological constraints, as defined in the CPSA Foundation - Level curriculum. For the technical systems architecture of embedded systems, + Level curriculum. For the technical system architecture of an embedded system, impact factors are often related to dependability and safety requirements, - performance, memory and real-time requirements, flexibility requirements and support - for different product variants and product lines. Examples for further + performance and real-time requirements, and flexibility requirements to + support different product variants and product lines. Examples for further considerations are physical proximity to sensors and actuators, limited - construction space, connectivity requirements, hardware cost, or development + construction space, connectivity requirements, hardware cost, and development schedules. -* Based on the impact-factor analysis, identify architectural issues and - develop solution strategies for topics such as error handling, resource - efficiency, real-time architectural design and variability. +* Based on the impact factors, identify architectural issues and develop + solution strategies for topics such as error handling, resource efficiency, + real-time architectural design and variability. -* Evaluate alternative technical systems architectures, and select a technical - systems architecture for further refinement. +* Evaluate alternative technical system architectures, and select a technical + system architecture for further refinement. * Hierarchically decompose the system into technical building blocks, and - establish a mapping to the elements of the functional architecture, if applicable. + establish a mapping to the elements of the functional architecture, if + applicable. * Map event chains to the technical architecture, if applicable: For example, - allocate a function to determine a measurement to a physical sensor, or allocate - an information flow to a bus. + allocate a function to determine a measurement to a physical sensor, or + allocate an information flow to a bus. -* Evaluate the defined technical systems architecture with regard to the impact +* Evaluate the defined technical system architecture with regard to the impact factors. -Participants know examples of how technical systems architectures can be modelled, +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 @@ -116,7 +117,7 @@ technical systems architecture: (e.g., single core, homogeneous multi core, heterogeneous multi core, amount of RAM, ROM, NVRAM, peripherals like sensors and actuators, custom hardware). -* Allocation of functional blocks to one or more control units, considering +* Allocation of function blocks to one or more control units, considering for example performance and isolation requirements. * Decide on the communication paradigm (e.g., time triggered vs. event triggered). @@ -125,7 +126,7 @@ technical systems architecture: both wired (e.g., ethernet, flexray, CAN), and wireless (e.g., Bluetooth, WiFi, cellular). -* Understand the challenges of distributed systems regarding latency, - throughput, lack of a global clock, impact on dependability. +Participants understand the challenges of distributed systems regarding latency, +throughput, lack of a global clock, and the impact on dependability. // end::EN[] diff --git a/docs/02-software-development/00-structure.adoc b/docs/02-software-development/00-structure.adoc index b41f925..fe220d4 100644 --- a/docs/02-software-development/00-structure.adoc +++ b/docs/02-software-development/00-structure.adoc @@ -5,7 +5,7 @@ // end::DE[] // tag::EN[] -== Software development for embedded systems +== Software Development for Embedded Systems // end::EN[] include::01-duration-terms.adoc[{include_configuration}] diff --git a/docs/02-software-development/02-learning-goals.adoc b/docs/02-software-development/02-learning-goals.adoc index 5f70df2..b23a3ba 100644 --- a/docs/02-software-development/02-learning-goals.adoc +++ b/docs/02-software-development/02-learning-goals.adoc @@ -13,20 +13,19 @@ Participants know different approaches for modeling software for embedded systems. They understand the basic concepts, strengths and weaknesses of these approaches: -* UML as a general-purpose modeling language. +* UML as a general-purpose modeling language * UML profiles to adapt UML to a specific domain (e.g., MARTE as a UML profile for modeling real-time systems). -* Graphical and textual domain-specific languages (e.g., AADL). +* Graphical and textual domain-specific languages (e.g., AADL) * State machines for modeling reactive systems. -* Modeling data- and signal-flows (e.g., function-block diagrams). +* Modeling data- and signal-flows (e.g., function-block diagrams) Participants understand how models can be used for analyzing the software, for -examples with regards to failures (e.g., FTA / FMEA), schedulability, error -propagation, and latency. +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. @@ -64,16 +63,16 @@ flexibility, predictability, performance and programming complexity: collection, automated reference counting, ownership / non-lexical scoping) and their trade-offs. -* Know the impact of systems-architectural decisions on memory management (e.g., - availability of memory management hardware like an MMU or MPU, CPU caches), - know software-based approaches to memory safety. +* Know the impact of system-architectural decisions on memory management (e.g., + amount of memory, availability of memory management hardware like an MMU or + MPU, CPU caches), know software-based approaches to memory safety. [[LG-2-4]] ==== LG 2-4: Error Handling 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. +variables, global error handlers, exceptions, monadic error handling (e.g., "Result" types, "Either" types). @@ -101,7 +100,7 @@ realization, and understand the trade-offs: * Using a model-based approach has the following potential costs: -** Creating a sufficiently detailed model requires significant effort and domain knowledge, which +** Creating a sufficiently detailed model requires significant effort, which needs to be weighed against the potential savings. ** Generated code often has increased resource demands. diff --git a/docs/03-dependability/02-learning-goals.adoc b/docs/03-dependability/02-learning-goals.adoc index fa67524..c115ac9 100644 --- a/docs/03-dependability/02-learning-goals.adoc +++ b/docs/03-dependability/02-learning-goals.adoc @@ -22,14 +22,14 @@ system: * Perform a hazard and risk analysis. -* Decide the kind of risk treatment (mitigate, eliminate, transfer or accept). +* Decide the kind of risk treatment (mitigate, eliminate, transfer, or accept). * Define and allocate safety requirements. -* Implement safety requirements on system, hardware and software level. +* Implement safety requirements on system, hardware, and software level. -* Analyze the system's residual risk, e.g. with FMEA and FTA, to verify that - an acceptable level of risk has been achieved. +* Analyze the system's residual risk to verify that an acceptable level of risk + has been achieved (e.g., with FMEA and FTA). Participants understand that functional safety must be considered on the system level, and impacts systems architecture, software architecture, and hardware @@ -62,7 +62,7 @@ Participants understand the process of safety classification: * By decomposing a building block, its associated risk can be distributed over and encapsulated in multiple building blocks. This can lead to a lower risk classification for the individual building blocks. To do so, freedom from - interference must to be ensured between these. + interference must be ensured between these building blocks. * The details of safety classification and decomposition are subject to specific norms and standards. @@ -96,7 +96,7 @@ fault-tolerant systems and how they interact with each other: undetected or unhandled errors may lead to system failure. * The externally observable behavior of component in the event of an error can - be classified as fail stop, fail operational, fail silent or fail consistent + be classified as fail stop, fail operational, fail silent, or fail consistent behavior. * Redundancy can help to build fault-tolerant systems. Homogeneous and @@ -117,8 +117,8 @@ fault-tolerant and safety-related systems: redundancy. Replication is applied to an architectural building block. Therefore, the sphere of replication has to be aligned with architectural building blocks. Strong cohesion and loose coupling principles - have to be taken into consideration for that. The concept of the sphere of replication can - also be applied to isolation zones with respect to memory regions (i.e., + have to be taken into consideration for that. The sphere of replication is + often aligned with isolation zones with respect to memory regions (i.e., address spaces) and control flows (i.e., threads). * Participants can select and apply architectural patterns and techniques to @@ -160,7 +160,7 @@ recommendations for processes and methods. ==== LG 3-8: Patterns for Detecting Errors and Failures Participants an select and apply patterns and techniques such as Checksum, -Parameter Checking, Heartbeat, Leaky-Bucket Counter, System Monitor, Watchdog, +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 @@ -179,7 +179,7 @@ Restart, Return to Reference Point, Rollback, Roll-Forward. [[LG-3-10]] ==== LG 3-10: Patterns for Error Mitigation -Participants can select and apply patterns for error mitigation such as Error-Correcting Codes and Marked Data. - +Participants can select and apply patterns for error mitigation such as +Error-Correcting Codes and Marked Data. // end::EN[] diff --git a/docs/04-realtime/00-structure.adoc b/docs/04-realtime/00-structure.adoc index acd5245..65c41ed 100644 --- a/docs/04-realtime/00-structure.adoc +++ b/docs/04-realtime/00-structure.adoc @@ -5,7 +5,7 @@ // end::DE[] // tag::EN[] -== Real time and concurrency +== Real-Time and Concurrency // end::EN[] include::01-duration-terms.adoc[{include_configuration}] diff --git a/docs/04-realtime/01-duration-terms.adoc b/docs/04-realtime/01-duration-terms.adoc index 3da5461..8020aaa 100644 --- a/docs/04-realtime/01-duration-terms.adoc +++ b/docs/04-realtime/01-duration-terms.adoc @@ -8,13 +8,14 @@ === Terms and Principles -Hard and firm vs. soft real-time requirements, cyclic executive and cyclic schedules, interrupts, real-time -operating systems, jobs, tasks, threads, processes, static vs dynamic -scheduling, time-triggered vs event-triggered real-time systems, priority -inversion, priority inheritance, priority ceiling, schedulability analysis, worst-case execution time (WCET), worst observed execution time (WOET), -execution time estimation, CPU load estimation, real-time architectural design -simulation and verification, concurrent resource access and coordination -techniques, black-box simulation vs. white-box simulation. +Hard and firm vs. soft real-time requirements, cyclic executive and cyclic +schedules, interrupts, real-time operating systems, jobs, tasks, threads, +processes, static vs dynamic scheduling, time-triggered vs event-triggered +real-time systems, priority inversion, priority inheritance, priority ceiling, +schedulability analysis, worst-case execution time (WCET), worst observed +execution time (WOET), execution time estimation, CPU load estimation, real-time +architectural design simulation and verification, concurrent resource access and +coordination techniques, black-box simulation vs. white-box simulation. // end::EN[] diff --git a/docs/04-realtime/02-learning-goals.adoc b/docs/04-realtime/02-learning-goals.adoc index adb0dc8..eb05a83 100644 --- a/docs/04-realtime/02-learning-goals.adoc +++ b/docs/04-realtime/02-learning-goals.adoc @@ -12,8 +12,8 @@ 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 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 @@ -76,8 +76,9 @@ Participants understand that real-time is a cross-cutting concern. ==== LG 4-3: Real-Time Requirements Participants are able to specify and model real-time requirements. They know -different approaches to specifying real-time requirements (e.g., UML, SysML, AADL) -and are able to select a suitable approach for a particular system. +different approaches to specifying real-time requirements (e.g., specifiying +real-time requirements in UML, SysML, or AADL) and are able to select a suitable +approach for a particular system. [[LG-4-4]]