Glanz: aiMOOC über GPT aiMOOC Action erstellt

2026-08-31T20:47:15Z

aiMOOC über GPT aiMOOC Action erstellt

Neue Seite

{{T}}
[[Category:English]]
[[Category:Engineering Design]]

{{BR}}
= Introduction =

Engineering design is the disciplined, creative process of turning needs into useful products, systems, processes, and services. In this university-level aiMOOC, you will work with the logic of professional design practice: identify stakeholders, formulate measurable requirements, generate and compare concepts, model behavior, make trade-offs, build prototypes, verify performance, validate usefulness, and consider manufacturing, risk, sustainability, ethics, and lifecycle consequences. The process is iterative rather than simply linear: new evidence can force you to revisit assumptions, requirements, concepts, or detailed design choices.

[[File:Engineering Design Process - NASA-JPL-Caltech.png|700px|frameless|center]]

The NASA/JPL-Caltech diagram illustrates a recognizable design loop from problem framing through research, ideation, prototyping, testing, and optimization. Different industries use different process models, but strong engineering design practice consistently links decisions to evidence and keeps stakeholder needs visible throughout development.

{{#ev:youtube|https://www.youtube.com/watch?v=GeUXQ_L-35M|500|center}}

Stanford's overview of design thinking is useful for connecting human-centered problem framing with rapid experimentation. In engineering, empathy and creativity must be combined with quantitative analysis, physical laws, safety, standards, and evidence.

{{BR}}
= Foundations of Engineering Design =

{{BR}}
== Problems, Needs, and Stakeholders ==

A design project should begin with the problem context rather than with a favorite solution. You need to identify who experiences the problem, who will use or maintain the solution, who pays for it, who regulates it, who might be affected by failures, and who bears environmental or social impacts. These people and organizations are [[English:Stakeholder|stakeholders]]. Their needs may conflict, so engineering design requires negotiation as well as calculation.

A useful problem statement describes the current situation, the desired outcome, the relevant context, and the boundaries of the project without locking the team into one implementation too early. At university level, you should distinguish a '''need''' from a '''requirement'''. A need expresses an intended benefit or capability; a requirement translates relevant needs into a statement that can guide design and later support verification.

{{BR}}
== Requirements and Constraints ==

Requirements make design intent testable. Good technical requirements are clear, feasible, singular, traceable, and verifiable. They should define what the system must achieve without unnecessarily prescribing how the designer must achieve it. Constraints limit the design space through factors such as budget, dimensions, mass, energy, regulations, schedule, available manufacturing processes, or operating environment.

[[File:House of Quality.jpg|600px|frameless|center]]

Quality Function Deployment and the [[English:House of Quality|House of Quality]] can connect the voice of the customer to measurable engineering characteristics. The method does not replace engineering judgment, but it helps teams make assumptions explicit, compare competing priorities, and preserve traceability between stakeholder concerns and technical decisions.

{{#ev:youtube|https://www.youtube.com/watch?v=J_y2I09rj_I|500|center}}

In systems engineering, requirements are also the foundation of later verification. A requirement such as "the device shall be lightweight" is too vague for rigorous acceptance. A better requirement would define a measurable mass limit and the conditions under which it is evaluated.

{{BR}}
== Functions and System Architecture ==

Before committing to geometry or components, ask what functions the system must perform. A functional decomposition breaks a high-level purpose into smaller functions such as sense, support, transmit, store, control, cool, protect, convert, or communicate. You can then explore different physical principles for realizing each function.

A [[English:System architecture|system architecture]] defines major elements, their responsibilities, and their interfaces. Architecture is important because many design problems occur not inside components but at interfaces between components, organizations, energy flows, information flows, and human operators. Clear interface definitions reduce integration risk and make change management more disciplined.

{{BR}}
= Concept Development and Decision Making =

{{BR}}
== Divergent and Convergent Thinking ==

Concept generation should initially be divergent: produce multiple genuinely different approaches before judging them. Useful methods include brainstorming, morphological charts, analogy, biomimicry, sketching, functional substitution, and reverse engineering of existing solutions. Premature convergence can make a team optimize the first plausible idea rather than explore the actual design space.

{{#ev:youtube|https://www.youtube.com/watch?v=gnWj97CEjeo|500|center}}

After divergence, design becomes convergent. Concepts are screened against requirements, feasibility, risk, and available evidence. The objective is not merely to find a concept that works, but to understand why it is preferable to alternatives under the chosen criteria.

{{BR}}
== Trade Studies and Multi-Criteria Decisions ==

Engineering decisions often involve competing objectives: lower mass can conflict with lower cost, higher stiffness can conflict with lower material use, and higher performance can conflict with reliability or maintainability. A trade study makes these conflicts explicit.

A simple decision matrix can score alternatives against weighted criteria, but you should treat scores as structured arguments rather than objective truth. Test the sensitivity of the ranking to uncertain weights and assumptions. For multi-objective problems, the concept of a [[English:Pareto efficiency|Pareto frontier]] is useful: a non-dominated design cannot improve one objective without worsening at least one other objective.

{{#ev:youtube|https://www.youtube.com/watch?v=sOkQ4HBmZXo|500|center}}

MIT OpenCourseWare's treatment of concept selection and tradespace exploration shows how systematic comparison can connect creative concepts with defensible engineering decisions.

{{BR}}
= Modeling, Analysis, and Detailed Design =

{{BR}}
== Sketches, CAD, and Technical Communication ==

Sketching remains valuable because it is fast and supports early reasoning. [[English:Computer-aided design|CAD]] becomes increasingly important as geometry stabilizes. Parametric models capture dimensions and relationships, assemblies reveal fit and interfaces, and engineering drawings communicate dimensions, tolerances, materials, finishes, and manufacturing intent.

[[File:CAD computer-aided design.jpg|600px|frameless|center]]

A CAD model is not proof that a design will work. It is a representation. Its value depends on geometry, assumptions, material data, boundary conditions, tolerances, and links to analysis and manufacturing. Strong designers know what information a model contains and what it leaves out.

{{BR}}
== Engineering Analysis and Models ==

Mathematical and computational models predict system behavior before costly prototypes are built. Depending on the discipline, you may use free-body diagrams, circuit models, heat-transfer models, fluid models, control models, statistical models, discrete-event models, or numerical simulation.

For structural design, the stress-strain relationship helps connect material behavior to allowable loads and deformations.

[[File:Stress-strain curve.svg|600px|frameless|center]]

The [[English:Finite element method|finite element method]] approximates field behavior by dividing a domain into many elements. It can estimate stress, deformation, thermal fields, vibration modes, and other quantities. Simulation results are only as trustworthy as the model assumptions, mesh quality, material properties, loads, boundary conditions, and validation evidence.

[[File:Finite element mesh.jpg|500px|frameless|center]]

A responsible analysis includes unit checks, order-of-magnitude estimates, limiting cases, sensitivity studies, and comparison with experiments or trusted benchmarks. A colorful simulation image is not evidence by itself.

{{BR}}
== Optimization and Robustness ==

Design optimization selects decision variables to improve one or more objectives while satisfying constraints. The mathematical optimum is not always the best engineering design because real systems face uncertainty, manufacturing variation, model error, changing loads, and incomplete information.

Robust design asks whether performance remains acceptable when uncertain parameters vary. Safety factors, margins, tolerances, statistical design methods, and uncertainty analysis are different ways of managing this reality. A university-level designer should be able to explain which uncertainties matter and how sensitive the design is to them.

{{#ev:youtube|https://www.youtube.com/watch?v=d44SDevJYR0|500|center}}

{{BR}}
= Prototyping, Testing, and Learning =

{{BR}}
== Prototypes as Questions ==

A prototype is most useful when it answers a specific question. A paper mock-up can test layout or interaction, a breadboard can test an electrical principle, a scale model can test geometry, and a functional prototype can test performance under realistic loads. The lowest-cost prototype that produces the needed evidence is often the right prototype for that stage.

[[File:Prototype circuit.jpg|600px|frameless|center]]

Rapid prototyping methods shorten learning cycles. Additive manufacturing can create complex forms quickly, but process limitations, anisotropy, surface finish, tolerances, material properties, and scale-up to production must still be considered.

[[File:3D printing functional prototypes.jpg|650px|frameless|center]]

{{BR}}
== Verification and Validation ==

'''Verification''' asks whether the implemented design satisfies its specified requirements. Methods can include inspection, analysis, demonstration, and test. '''Validation''' asks whether the resulting system actually meets stakeholder needs in its intended context. A system can pass verification and still fail validation if the requirements were incomplete or misguided.

A strong verification plan defines each requirement, the verification method, the test conditions, the instrumentation, acceptance criteria, data handling, and responsibility. A strong validation plan includes realistic users, environments, operating scenarios, and lifecycle conditions.

{{BR}}
== Integration and Interface Management ==

Subcomponents that work individually may still fail when integrated. Mechanical fit, electrical compatibility, timing, software protocols, thermal interactions, fluid connections, tolerances, and human procedures can all create interface failures. Interface control documents, configuration management, integration sequencing, and disciplined change control are therefore central to complex design.

{{#ev:youtube|https://www.youtube.com/watch?v=9AtMQqCBdhw|500|center}}

{{BR}}
= Risk, Reliability, Safety, and Ethics =

{{BR}}
== Risk and Failure Thinking ==

Risk combines the possibility of an unwanted event with its consequences. Engineering teams use tools such as risk registers, hazard analysis, fault trees, event trees, and [[English:Failure mode and effects analysis|FMEA]] to identify problems before they become failures. Good risk work does not end with listing hazards; it assigns mitigation actions, owners, evidence, and residual risk.

Reliability concerns the probability that a system performs as required for a specified time under stated conditions. Reliability must be designed into architecture, components, interfaces, diagnostics, maintenance strategy, and operating procedures. Redundancy can improve resilience, but it can also add cost, mass, complexity, and common-cause failure modes.

{{BR}}
== Safety and Professional Responsibility ==

Safety is not an optional criterion to be traded away casually. Designers should identify foreseeable misuse, abnormal conditions, vulnerable users, and failure consequences. Protective measures should favor eliminating hazards or reducing them by design before relying only on warnings or user behavior.

Engineering ethics also includes honesty about evidence, limits, uncertainty, conflicts of interest, accessibility, fairness, privacy, environmental effects, and long-term consequences. A professional engineer should be able to explain not only whether a design can be built, but whether the design is responsible in its context.

{{BR}}
= Manufacturing, Lifecycle, and Sustainability =

{{BR}}
== Design for Manufacturing and Assembly ==

A prototype that works in a laboratory may be expensive or impossible to manufacture at scale. [[English:Design for manufacturability|Design for manufacturing]] considers process capability, part count, tooling, tolerances, standard components, inspection, assembly sequence, supply chains, and production rate. Design for assembly seeks to simplify orientation, joining, access, error prevention, and service.

Tolerance design deserves special attention. Extremely tight tolerances raise cost and may not improve function. Tolerance allocation should be linked to functional needs, manufacturing capability, measurement systems, and stack-up analysis.

{{BR}}
== Lifecycle Thinking and Sustainable Design ==

Engineering decisions create impacts during material extraction, manufacturing, distribution, use, maintenance, repair, reuse, recycling, and disposal. [[English:Life-cycle assessment|Life-cycle assessment]] provides a structured way to compare environmental impacts across a defined system boundary. Its conclusions depend on assumptions about functional units, data quality, allocation, geographic context, energy systems, lifetime, and end-of-life pathways.

[[File:Engineering the Circular Economy Lifecycle by Rebecca Meldrum wiki-2.png|700px|frameless|center]]

Circular design strategies include durability, repairability, modularity, upgradeability, remanufacturing, reuse, material recovery, and reduction of hazardous or scarce inputs. You should also check for burden shifting: reducing one impact category can increase another.

{{BR}}
= Teamwork, Documentation, and Design Reviews =

Engineering design is collaborative. Teams need shared definitions, version control, traceable decisions, clear roles, and mechanisms for constructive disagreement. A design notebook or decision log should record assumptions, calculations, alternatives, evidence, test results, and reasons for major changes.

Formal design reviews create decision points. Depending on the project, these may include a requirements review, concept review, preliminary design review, critical design review, test readiness review, or production readiness review. A useful review is evidence-based: reviewers should be able to trace a decision from stakeholder need through requirement, design rationale, analysis, prototype, and test evidence.

{{BR}}
= Interactive Tasks =

{{BR}}
== Quiz: Test Your Knowledge ==

{{MC}}

'''What best distinguishes a requirement from a design solution?'''
(A requirement states what must be achieved)
(!A requirement always specifies the final geometry)
(!A requirement is only a customer opinion)
(!A requirement is created after testing)

{{E}}
<br>

{{MC}}

'''Why is early concept generation usually divergent?'''
(It expands the range of possible solutions)
(!It eliminates the need for requirements)
(!It guarantees the cheapest design)
(!It replaces engineering analysis)

{{E}}
<br>

{{MC}}

'''What does verification primarily check?'''
(Compliance with specified requirements)
(!Customer satisfaction with market price)
(!Whether every stakeholder agrees)
(!Whether a concept is visually attractive)

{{E}}
<br>

{{MC}}

'''What does validation primarily check?'''
(Fitness for stakeholder needs in context)
(!Whether every CAD dimension is constrained)
(!Whether all parts use one material)
(!Whether manufacturing has started)

{{E}}
<br>

{{MC}}

'''What is the main purpose of a trade study?'''
(To compare alternatives against explicit criteria)
(!To avoid documenting design decisions)
(!To select the first feasible concept)
(!To replace prototypes with opinions)

{{E}}
<br>

{{MC}}

'''Why is a finite element result not automatically trustworthy?'''
(It depends on assumptions and model quality)
(!It can only be used for electrical circuits)
(!It never uses material properties)
(!It cannot represent boundary conditions)

{{E}}
<br>

{{MC}}

'''What is a key benefit of prototyping?'''
(It produces evidence about design assumptions)
(!It guarantees mass production readiness)
(!It removes the need for testing)
(!It fixes all requirements permanently)

{{E}}
<br>

{{MC}}

'''Why are interfaces important in system design?'''
(Interactions between elements can create failures)
(!Interfaces matter only in software projects)
(!Interfaces eliminate the need for integration)
(!Interfaces are unrelated to requirements)

{{E}}
<br>

{{MC}}

'''What is a central goal of design for manufacturing?'''
(To align the design with capable production processes)
(!To maximize the number of unique parts)
(!To require the tightest tolerance everywhere)
(!To delay manufacturing considerations until launch)

{{E}}
<br>

{{MC}}

'''What does lifecycle thinking encourage a designer to consider?'''
(Impacts from material extraction through end of life)
(!Only the purchase price of the product)
(!Only the appearance of the prototype)
(!Only the first manufacturing operation)

{{E}}
<br>

{{BR}}
== Memory Game ==

<div class="memo-quiz">
{|
|-
| Requirement || A measurable statement of what a system must achieve
|-
| Prototype || A representation built to answer design questions
|-
| Verification || Evidence that specified requirements are satisfied
|-
| Validation || Evidence that stakeholder needs are met in context
|-
| Trade study || Structured comparison of design alternatives
|-
| Interface || Boundary where system elements interact
|}
{{E}}
<br>

{{BR}}
== Drag and Drop ==

<div class="lueckentext-quiz">

{| class="wikitable"
! Match the correct terms.
! Topic
|-
| '''Stakeholder need'''
| Describes the desired benefit or capability
|-
| '''Technical requirement'''
| Defines a measurable condition for acceptance
|-
| '''Concept generation'''
| Produces multiple possible solution approaches
|-
| '''Design verification'''
| Checks the implemented design against requirements
|-
| '''Design validation'''
| Checks usefulness in the intended context
|}
{{E}}

<br>
...
<br />

{{BR}}
== Crossword Puzzle ==

<div class="kreuzwort-quiz">
{|
|-
| Requirements || What measurable statements guide design and later acceptance?
|-
| Prototype || What do engineers build to answer a focused design question?
|-
| Verification || What process checks whether specified requirements are met?
|-
| Validation || What process checks whether stakeholder needs are met in context?
|-
| Reliability || What term describes dependable performance over time under stated conditions?
|-
| Optimization || What process searches for improved design variables subject to objectives and constraints?
|}
{{E}}
<br>

{{BR}}
== LearningApps ==

<iframe> https://learningapps.org/index.php?s=Engineering+Design </iframe>

{{BR}}
== Cloze Text ==

<quiz display=simple>
{'''Complete the text.'''<br>
|type="{}"}
Engineering design begins by understanding { stakeholder needs }. Measurable { requirements } translate relevant needs into conditions that can guide development. During concept development, teams should create { alternatives } before converging on one approach. Models and simulations require explicit { assumptions } and should be checked against evidence. A prototype is most valuable when it answers a specific { question }. Verification compares the implemented design with { requirements }. Validation evaluates the solution in its intended { context }. Lifecycle thinking considers impacts through manufacturing, use, maintenance, and { end of life }.
</quiz>

<br>

{{BR}}
= Open-Ended Tasks =

{{BR}}
=== Easy ===
# [[English:Stakeholder Map|Stakeholder Map]]: Choose a familiar engineered product and create a stakeholder map showing users, maintainers, regulators, producers, and people affected by failure or disposal.
# [[English:Requirement Rewrite|Requirement Rewrite]]: Find five vague design statements and rewrite each as a clear, measurable, and verifiable requirement.
# [[English:Concept Sketching|Concept Sketching]]: Produce six sketches for different ways to solve one simple engineering problem and annotate the physical principle used in each.
# [[English:Prototype Reflection|Prototype Reflection]]: Build a low-cost prototype from paper, cardboard, or simple components and record which design question it answers.

{{BR}}
=== Standard ===
# [[English:Trade Study|Trade Study]]: Define at least five weighted criteria, compare three engineering concepts, perform a sensitivity check, and justify your final recommendation.
# [[English:CAD Design Review|CAD Design Review]]: Create a parametric CAD model of a simple component, identify critical dimensions and tolerances, and explain how manufacturing constraints influenced the model.
# [[English:Engineering Experiment|Engineering Experiment]]: Plan and carry out a controlled test of a material, structure, mechanism, circuit, or thermal component and compare measured results with a simple predictive model.
# [[English:Engineer Interview|Engineer Interview]]: Interview a practicing engineer about how requirements, reviews, prototypes, failures, and documentation shape real design work, then synthesize the findings.

{{BR}}
=== Advanced ===
# [[English:Multidisciplinary Design Project|Multidisciplinary Design Project]]: In a team, design a system that combines at least two engineering disciplines, define interfaces, build a prototype, and document integration evidence.
# [[English:Uncertainty Analysis|Uncertainty Analysis]]: Select a quantitative design model, identify uncertain inputs, run a sensitivity or Monte Carlo analysis, and recommend changes that make the design more robust.
# [[English:Sustainable Redesign|Sustainable Redesign]]: Redesign an existing product for repair, reuse, disassembly, or lower lifecycle impact and support the proposal with a transparent comparison of trade-offs.
# [[English:Design Review Video|Design Review Video]]: Produce a concise technical review video presenting stakeholder needs, requirements, alternatives, analysis, risks, prototype evidence, test results, and remaining uncertainties.

{{:Open Task - Create a MOOC}}

{{BR}}
= Learning Assessment =

# [[English:Requirements Traceability Assessment|Requirements Traceability Assessment]]: Given a design brief, create a traceability chain from stakeholder need to measurable requirement, design feature, verification method, and acceptance criterion, then explain weaknesses in the chain.
# [[English:Concept Selection Assessment|Concept Selection Assessment]]: Compare three plausible concepts using both qualitative engineering judgment and a quantitative decision method, then test whether your recommendation changes when weights or uncertain scores vary.
# [[English:Model Credibility Assessment|Model Credibility Assessment]]: Audit a provided simulation by identifying assumptions, boundary conditions, missing validation evidence, sensitivity risks, and at least one independent check.
# [[English:Failure Investigation Assessment|Failure Investigation Assessment]]: Analyze a hypothetical product failure, distinguish component and interface causes, propose mitigations, and explain how the design process should change to prevent recurrence.
# [[English:Lifecycle Transfer Assessment|Lifecycle Transfer Assessment]]: Evaluate how a design optimized for laboratory performance would need to change for manufacturing, maintenance, user safety, sustainability, and end-of-life recovery.
# [[English:Integrated Design Defense|Integrated Design Defense]]: Present and defend a design to a review panel using traceable evidence, then respond to a change in one major requirement without losing configuration control.

<br>
<br>

{{BR}}
= Evidence of Learning =

'''Knowledge:''' You can explain iterative engineering design, stakeholder analysis, requirements, functional decomposition, architecture, concept selection, modeling, prototyping, verification, validation, risk, manufacturing, and lifecycle thinking.

'''Analytical skill:''' You can make assumptions explicit, choose appropriate models, check units and limiting cases, interpret simulation results, evaluate uncertainty, and connect quantitative evidence to design decisions.

'''Design skill:''' You can generate multiple concepts, compare them transparently, create technical representations, design prototypes and experiments, and revise a solution using evidence.

'''Professional practice:''' You can document requirements, interfaces, test criteria, risks, design rationale, change history, and review outcomes so that decisions remain traceable.

'''Products:''' Strong evidence can include a requirements set, concept portfolio, trade study, CAD model, analysis notebook, prototype, test report, risk register, lifecycle comparison, design review, and reflective design log.

'''Transfer:''' You can apply the same reasoning to new engineering domains by separating stakeholder needs, functional goals, physical principles, constraints, evidence, and lifecycle consequences.

<br>
<br>

{{BR}}
= OERs on the Topic =

<iframe> https://en.m.wikipedia.org/wiki/Engineering_design_process </iframe>

<br>

Useful related open learning areas include [[English:Systems engineering|Systems engineering]], [[English:Computer-aided design|Computer-aided design]], [[English:Finite element method|Finite element method]], [[English:Prototyping|Prototyping]], [[English:Engineering optimization|Engineering optimization]], [[English:Failure mode and effects analysis|Failure mode and effects analysis]], [[English:Life-cycle assessment|Life-cycle assessment]], and [[English:Design for manufacturability|Design for manufacturability]].

{{BR}}
= Linked Learning Areas =

{| align=center
{{:D-Tab}}
'''[[English:Engineering Design|Engineering Design]]'''
# [[English:Stakeholder analysis|Stakeholder analysis]]
# [[English:Engineering requirement|Engineering requirement]]
# [[English:Functional decomposition|Functional decomposition]]
# [[English:System architecture|System architecture]]
# [[English:Concept generation|Concept generation]]
# [[English:Trade study|Trade study]]
# [[English:Computer-aided design|Computer-aided design]]
# [[English:Engineering analysis|Engineering analysis]]
# [[English:Prototyping|Prototyping]]
# [[English:Verification and validation|Verification and validation]]
# [[English:Reliability engineering|Reliability engineering]]
# [[English:Design for manufacturability|Design for manufacturability]]
# [[English:Life-cycle assessment|Life-cycle assessment]]
|}

{{BR}}
= aiMOOC Projects =
[[Category:English]]
[[Category:Engineering Design]]
[[Category:Higher Education]]
[[Category:Engineering]]
[[Category:Mechanical Engineering]]
[[Category:Systems Engineering]]
[[Category:Product Design]]
[[Category:Design Engineering]]
[[Category:AI_MOOC]]
[[Category:GPT aiMOOC]]
{{MT}}

English:Engineering Design - Versionsgeschichte

Glanz: aiMOOC über GPT aiMOOC Action erstellt