2021.1 (#10)

* Unify systems vs system architecture etc

* Use title case for learning goal

* Fix typos

Co-authored-by: Florian Franzmann <[email protected]>

docs/00b-basics/01-what-to-expect-of-this-module.adoc

@@ -16,17 +16,17 @@ achieved:
 
 * systems must be highly reliable and are often safety-critical
 
-* systems must react to events in their enviroment in a timely, predictable way,
-  leading to hard realtime requirements
+* systems must react to events in their environment in a timely, predictable way,
+  leading to hard real-time requirements
 
 * systems need to be adaptable to quickly react to changing market requirements
 
 The module “{curriculum-short}” conveys a methodical approach to architecture
 design for dependable embedded systems. It shows how software architecture
-interacts with the overall system architecture, and how the requirements with
-regards to safety, dependability, realtime and adaptability are adressed in a
+interacts with the overall systems architecture, and how the requirements with
+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 adresses the analysis of
+appropriate software architectures, the module also addresses the analysis of
 software architectures with regard to the required quality characteristics.
 
 // end::EN[]

docs/01-system-development/01-duration-terms.adoc

@@ -8,7 +8,7 @@
 
 === Terms and Principles
 
-System architecture, functional architecture, technical system architecture,
-event chain, system development, software development, hardware development
+Systems architecture, functional architecture, technical systems architecture,
+event chain, systems development, software development, hardware development.
 
 // end::EN[]

docs/01-system-development/02-learning-goals.adoc

@@ -6,41 +6,41 @@
 // tag::EN[]
 
 [[LG-1-1]]
-==== LG 1-1: Systematic approach to systems development
+==== LG 1-1: Systematic Approach to Systems Development
 
 Participants understand the systematic approach to systems development:
 
 * Participants understand the cross-cutting nature of aspects like time
   behavior, dependability and safety with regards to system-, software- and
-  hardware-develoment, and the necessity to address these with an integrated
+  hardware-development, and the necessity to address these with an integrated
   systems development approach.
 
 * Participants understand that systems development follows an iterative approach
   that includes both top-down activities like working with models, estimations
   and simulations, and bottom-up activities like tests and measurements on real
-  systems to validate the estimations and simulations.
+  systems to validate the estimates and simulations.
 
 * Participants understand that modeling and model-based analysis enable the
   evaluation of different architectures in a cost-efficient way. Model-based
   approaches therefore enable a more thorough exploration of the design space.
 
 * Participants understand the costs and benefits of developing and maintaining
   multiple architectural abstraction levels, such as functional and technical
-  system architectures: A functional architecture enables reasoning about a
+  systems architectures: A functional architecture enables reasoning about a
   system in a way that is independent of a specific technical realization and
   allows for different technical variants. These benefits need to be weighed
   against the costs for developing and maintaining several architectural
   models.
 
-* Participants know methods and frameworks for model-based system development,
+* Participants know methods and frameworks for model-based systems development,
   such as Harmony <<douglass>>, SYSMOD <<weilkiens>>.
 
 * Participants understand that development approaches for embedded systems are
   often subject to domain specific standards.
 
 
 [[LG-1-2]]
-==== LG 1-2: Modeling and analysis of functional architectures
+==== LG 1-2: Modeling and Analysis of Functional Architectures
 
 Participants can apply a systematic approach to modeling and analysis of
 functional architectures:
@@ -62,70 +62,70 @@ 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 how functional architectures can be modelled,
-for example with SysML or FAS <<weilkiens-mbsa>>..
+Participants know examples of how functional architectures can be modelled,
+e.g. with SysML or FAS <<weilkiens-mbsa>>..
 
 
 [[LG-1-3]]
-==== LG 1-3: Modeling and analysis of technical system architectures
+==== LG 1-3: Modeling and Analysis of Technical Systems Architectures
 
 Participants understand the systematic approach to modeling and analysis of
-technical system architectures:
+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 system architecture of embedded systems,
+  Level curriculum. For the technical systems architecture of embedded systems,
   impact factors are often related to dependability and safety requirements,
-  performance and real-time requirements, flexibility requirements and support
+  performance, memory and real-time requirements, flexibility requirements and support
   for 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
   schedules.
 
-* Based on the impact factors analysis, identify architectural issues and
+* 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
+  efficiency, real-time architectural design and variability.
 
-* Evaluate alternative technical system architectures, and select a technical
-  system architecture for further refinement
+* Evaluate alternative technical systems architectures, and select a technical
+  systems 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
+  an information flow to a bus.
 
-* Evaluate the defined technical system architecture with regard to the impact
-  factors
+* Evaluate the defined technical systems architecture with regard to the impact
+  factors.
 
-Participants know examples how technical system architectures can be modelled,
+Participants know examples of how technical systems architectures can be modelled,
 for example with SysML.
 
-Participants understand that the design of a technical system architecture is an
+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 system architecture:
+technical systems architecture:
 
-* How a function block is realized, for example in software, with an ASIC, an
-  FPGA, or a combination of these
+* How a function block is implemented, for example in software, with an ASIC, an
+  FPGA, or a combination of these.
 
 * Deciding the number of control units and their hardware characteristics
   (e.g., single core, homogeneous multi core, heterogeneous multi core, amount of
-  RAM, ROM, NVRAM, peripherals like sensors and actuators, custom hardware)
+  RAM, ROM, NVRAM, peripherals like sensors and actuators, custom hardware).
 
-* Allocation of function blocks to one or more control units, considering
-  for example performance and isolation requirements
+* Allocation of functional 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)
+* Decide on the communication paradigm (e.g., time triggered vs. event triggered).
 
 * Decide on network topologies (e.g., bus vs. star) and network technologies,
   both wired (e.g., ethernet, flexray, CAN), and wireless (e.g., Bluetooth,
-  WiFi, cellular)
+  WiFi, cellular).
 
 * Understand the challenges of distributed systems regarding latency,
-  throughput, lack of a global clock, impact on dependability
+  throughput, lack of a global clock, impact on dependability.
 
 // end::EN[]

docs/02-software-development/02-learning-goals.adoc

@@ -7,22 +7,22 @@
 
 
 [[LG-2-1]]
-==== LG 2-1: Modeling software for embedded systems
+==== LG 2-1: Modeling Software for Embedded Systems
 
 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)
+  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
+* 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
@@ -33,17 +33,17 @@ requirements and boundary conditions of the system under development.
 
 
 [[LG-2-2]]
-==== LG 2-2: Implementing software for embedded systems
+==== LG 2-2: Implementing Software for Embedded Systems
 
 Participants understand how programming languages influence quality
 characteristics and cross-cutting concepts:
 
 * Impact of the programming language on analyzability (e.g., with static
-  and dynamic analysis tools)
+  and dynamic analysis tools).
 
 * Impact of the programming language abstractions and concepts for concurrency,
   memory management and error handling on cross-cutting concepts and
-  dependability
+  dependability.
 
 Participants know different programming language paradigms (e.g., procedural,
 object-oriented, functional). Participants know examples for programming languages
@@ -52,75 +52,76 @@ understand their strengths and weaknesses.
 
 
 [[LG-2-3]]
-==== LG 2-3: Memory management
+==== LG 2-3: Memory Management
 
-Participants understand how memory management strategies and memory management
-related capabilities of the programming language affect memory safety,
+Participants understand how memory management strategies and memory-management-related
+capabilities of the programming language affect memory safety,
 flexibility, predictability, performance and programming complexity:
 
-* Understand the tradeoffs in choosing dynamic or static allocation of memory
+* Understand the trade-offs in choosing dynamic or static allocation of memory.
 
 * Know managed approaches to dynamically allocated memory (e.g., garbage
   collection, automated reference counting, ownership / non-lexical scoping) and
-  their tradeoffs
+  their trade-offs.
 
-* Know the impact of system architectural decisions on memory management (e.g.,
+* 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 software-based approaches to memory safety.
 
 [[LG-2-4]]
-==== LG 2-4: Error handling
+==== 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, options
+variables, global error handlers, exceptions, monadic error handling (e.g.
+"Result" types, "Either" types).
 
 
 [[LG-2-5]]
-==== LG 2-5: Model-based development of embedded systems
+==== LG 2-5: Model-Based Development of Embedded Systems
 
 Participants know how models can be used to generate artifacts for the
-realization, and understand the tradeoffs:
+realization, and understand the trade-offs:
 
 * Different kinds of models and model elements can be used: structural models
   (e.g., UML component models, AADL) and behavioral models (e.g., statecharts,
-  activity diagrams)
+  activity diagrams).
 
 * Different kinds artifacts can be generated, e.g. implementation code, test
-  cases, configurations, or analysis models
+  cases, configurations, or analysis models.
 
 * Using a model-based approach can have the following benefits:
 
-** Reduced effort, since these artifacts do not have to be created manually
+** Reduced effort since these artifacts do not have to be created manually.
 
-** Increased quality, since manual errors can be eliminated
+** Increased quality since manual errors can be eliminated.
 
 ** Can support adaptibility in a resource-efficient way by resolving variability
-   during code generation
+   during code generation.
 
 * Using a model-based approach has the following potential costs:
 
-** Creating a sufficiently detailed model requires significant effort, which
-   needs to be weighed against the potential savings
+** Creating a sufficiently detailed model requires significant effort and domain knowledge, which
+   needs to be weighed against the potential savings.
 
-** Generated code often has increased resource demands
+** Generated code often has increased resource demands.
 
-** Potential vendor lock-in, specifically with commercial tools
+** Potential vendor lock-in, specifically with commercial tools.
 
 ** The generated code may be of insufficient quality or not suitable for the
-   target platform
+   target platform.
 
 ** Using a model-based approach in a safety-critical environment may lead to
-   significant tool qualification efforts
+   significant tool qualification efforts.
 
 
 
 [[LG-2-6]]
-==== LG 2-6: Verification of embedded software
+==== LG 2-6: Verification of Embedded Software
 
 Participants can explain and give examples for different error categories
-(e.g. memory management errors, synchronization errors, type defects, timing
-errors).
+(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:
@@ -134,7 +135,7 @@ and know the limitations of these techniques:
   tools.
 
 [[LG-2-7]]
-==== LG 2-7: Design paradigms
+==== LG 2-7: Design Paradigms
 
 Participants know design principles and paradigms for embdded software, such as
 design by contract, the robustness principle, or defensive programming.

docs/03-dependability/01-duration-terms.adoc

@@ -10,7 +10,7 @@
 
 Dependability, safety, availability, reliability, fault tolerance, security,
 fault, error, failure, fault prevention, error detection, error recovery, error
-mitigation, redundancy, replication, fail-safe vs fail-operational, fail-silent,
-fail-stop, fail-consistent, freedom from interference
+mitigation, redundancy, replication, fail safe vs fail operational, fail silent,
+fail stop, fail consistent, freedom from interference.
 
 // end::EN[]