Fix typos

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

@@ -123,7 +123,7 @@ technical systems architecture:
 * 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,
+  both wired (e.g., Ethernet, FlexRay, CAN), and wireless (e.g., Bluetooth,
   WiFi, cellular).
 
 Participants understand the challenges of distributed systems regarding latency,

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

@@ -83,10 +83,10 @@ Participants know how models can be used to generate artifacts for the
 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,
+  (e.g., UML component models, AADL) and behavioral models (e.g., state charts,
   activity diagrams).
 
-* Different kinds artifacts can be generated, e.g. implementation code, test
+* Different kinds of artifacts can be generated, e.g. implementation code, test
   cases, configurations, or analysis models.
 
 * Using a model-based approach can have the following benefits:
@@ -95,7 +95,7 @@ realization, and understand the trade-offs:
 
 ** Increased quality since manual errors can be eliminated.
 
-** Can support adaptibility in a resource-efficient way by resolving variability
+** Can support adaptability in a resource-efficient way by resolving variability
    during code generation.
 
 * Using a model-based approach has the following potential costs:
@@ -136,7 +136,7 @@ and know the limitations of these techniques:
 [[LG-2-7]]
 ==== LG 2-7: Design Paradigms
 
-Participants know design principles and paradigms for embdded software, such as
+Participants know design principles and paradigms for embedded software, such as
 design by contract, the robustness principle, or defensive programming.
 
 // end::EN[]

docs/04-realtime/02-learning-goals.adoc

@@ -50,7 +50,7 @@ systems:
 * Map logical tasks to jobs.
 
 * Decide on technical solutions (e.g., RTOS tasks), and allocate jobs to the
-  the technical solution elements.
+  technical solution elements.
 
 * Implement the real-time architectural design.
 
@@ -76,8 +76,8 @@ 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., specifiying
-real-time requirements in UML, SysML, or AADL) and are able to select a suitable
+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.
 
 
@@ -138,7 +138,7 @@ RTOS-based event-triggered approach:
 * Participants can define the RTOS-tasks and their characteristics.
 
 * Participants can describe important timing properties of RTOSes and hardware
-  (i.e. interrupt latency, scheduling latency, dispatch latency)
+  (e.g., interrupt latency, scheduling latency, dispatch latency)
 
 Application-level interrupt handling:
 
@@ -175,7 +175,7 @@ elements which share the same software resources to the same RTOS task).
 
 Participants understand how deadlocks occur and how they can be avoided.
 
-Partipants understand priority inversion and know solution approaches (priority
+Participants understand priority inversion and know solution approaches (priority
 ceiling, priority inheritance).
 
 
@@ -255,8 +255,8 @@ Shared resource analysis:
 ==== LG 4-9: Tools for Real-Time Architectural Design and Analysis
 
 Participants understand that tools for specification, design and analysis of
-real-time systems are needed for complex embedded systems with a large number of
-external real-time requirements.
+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

docs/05-adaptability/02-learning-goals.adoc

@@ -18,7 +18,7 @@ Participants know possible binding times when variability can be resolved
 
 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
+safety, security, and backwards compatibility) and complementing quality goals
 (e.g., maintainability, reusability).
 
 Participants know high level approaches to adaptability and variability such as
@@ -36,7 +36,7 @@ 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.
+architectures, and technical architectures.
 
 [[LG-5-3]]
 ==== LG 5-3: Supporting Adaptability and Variability
@@ -67,7 +67,7 @@ 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.
+requirements (e.g., by refactoring).
 
 Participants know approaches how to handle system and software updates, as well
 as trade-offs of updates.