Minor editorial and stilistic changes

Harmonize use of title case
Harmonize use of "system" vs. "systems"
Use periods only for complete sentences
Remove requirement for domain knowledge from LG 2-5, since this is not specific
to model-based development
Move memory constraints from chapter 1 to chapter 2

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.

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)

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[]
 
 

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[]

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 <<weilkiens-mbsa>>..
+Participants know examples of how functional architectures can be modeled (e.g.,
+with SysML or FAS <<weilkiens-mbsa>>).
 
 
 [[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[]

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}]

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.

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[]

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}]

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[]

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]]