Mathematical Modeling in Engineering: How Models Support Design, Simulation, Safety, and Optimization

Last Updated June 13, 2026

Mathematical modeling in engineering uses formal representations to design systems, evaluate alternatives, simulate performance, test constraints, optimize tradeoffs, estimate risk, and support safe, reliable, and accountable decisions. Engineering models connect physical principles, design requirements, materials, loads, tolerances, costs, uncertainty, constraints, failure modes, and operating conditions.

In engineering, models are not only tools for explanation. They are tools for making things work. A model may support the design of a bridge, aircraft component, water system, circuit, control system, production process, software architecture, energy grid, medical device, or infrastructure network.

Responsible engineering modeling requires clear requirements, explicit assumptions, validated equations, tested simulations, uncertainty assessment, safety margins, sensitivity analysis, verification, documentation, and communication of use limits. A model that is mathematically elegant but unsafe for the design context is not an adequate engineering model.

Engineering models are powerful because they make design reasoning explicit. They show what is being optimized, what constraints must be respected, what failure modes are possible, what uncertainty remains, and what evidence supports safe use. Their value lies not only in prediction, but in disciplined design judgment.

Why Modeling Matters in Engineering

Mathematical modeling matters in engineering because engineered systems must perform under constraints. Engineers must design for loads, flows, temperatures, pressures, currents, tolerances, vibrations, costs, materials, failures, users, environments, maintenance, and uncertainty. Models allow these relationships to be represented before, during, and after physical implementation.

Engineering modeling is therefore both analytical and practical. It helps engineers ask whether a design will work, how it might fail, which alternative is preferable, what margin of safety exists, which constraint is binding, and what evidence is needed before deployment.

Engineering models make design accountable by forcing assumptions, constraints, evidence, and tradeoffs into reviewable form.

Back to top ↑

What Engineering Models Do

Engineering models serve many purposes. Some estimate physical behavior. Some test whether a design meets requirements. Some optimize a system under competing constraints. Some simulate failure modes. Some support control, monitoring, maintenance, or lifecycle planning.

The model’s purpose determines what counts as adequacy. A rough sizing model may be useful early in design. A certified safety model requires stronger evidence, validation, traceability, and review.

Good engineering modeling begins by naming the model’s role. A conceptual design model should not be mistaken for a validated safety model. A simulation output should not be treated as field evidence unless its assumptions, verification, and validation support that use.

Back to top ↑

Requirements, Constraints, and Design Intent

Engineering models are shaped by requirements. Requirements describe what the system must do, where it must operate, what constraints it must respect, and what consequences matter. A model without requirements may be mathematically interesting but engineering-incomplete.

Design intent translates goals into formal variables, objectives, constraints, thresholds, tolerances, and acceptance criteria. This is where engineering judgment enters the model.

Engineering models should make requirements visible. Otherwise, users may see a result without understanding what design problem the model actually solved.

Back to top ↑

Physics, Materials, and System Behavior

Many engineering models are grounded in physical principles: conservation of mass, energy, and momentum; equilibrium; thermodynamics; electromagnetism; material behavior; fluid dynamics; chemical kinetics; control theory; and systems dynamics.

But engineering models also depend on material properties, boundary conditions, manufacturing processes, operating environments, and system interactions. A physical law may be general, but its engineering model is contextual.

Engineering model quality depends on how well these ingredients match the actual design context. The same equation can be safe in one context and inadequate in another.

Back to top ↑

Loads, Stress, Failure, and Safety Margins

Engineering models often focus on whether systems can withstand loads, stresses, pressures, currents, temperatures, vibrations, or other demands. Failure modeling asks how a system might break, degrade, become unstable, lose function, or exceed acceptable risk.

Safety margins are central because engineering decisions must account for uncertainty. Material properties vary. Loads may be underestimated. Manufacturing tolerances matter. Operating conditions can exceed expectations. Models must therefore support not only expected performance, but resilience under plausible variation.

A model that predicts ordinary performance but ignores failure modes is incomplete for many engineering uses.

Back to top ↑

Simulation and Digital Prototyping

Simulation allows engineers to test designs virtually before building, deploying, or modifying physical systems. Digital prototyping can reduce cost, reveal failure risks, compare alternatives, explore extreme conditions, and improve design iteration.

However, simulation is not automatically reality. Simulation results depend on governing equations, mesh resolution, numerical methods, material models, boundary conditions, assumptions, calibration, and verification.

Digital prototypes are most useful when treated as evidence to be verified, validated, and interpreted—not as substitutes for engineering accountability.

Back to top ↑

Optimization and Engineering Tradeoffs

Engineering often involves competing objectives. A design may need to be strong but lightweight, efficient but affordable, safe but maintainable, fast but stable, precise but manufacturable, or high-performing but robust under uncertainty.

Optimization models formalize these tradeoffs through objective functions and constraints. But optimization does not remove judgment. The objective, constraints, weights, penalties, and feasible alternatives reflect design priorities.

Engineering optimization is responsible when tradeoffs are explicit and the selected design is reviewed against real-world consequences, not only mathematical optimality.

Back to top ↑

Control, Feedback, and Dynamic Systems

Many engineered systems operate dynamically. They respond to changing inputs, disturbances, users, sensors, actuators, and environments. Control models help engineers design systems that remain stable, responsive, efficient, and safe over time.

Feedback is powerful because it allows correction. It is also risky because poorly designed feedback can amplify instability, oscillation, delay, overshoot, or cascading failure.

Control modeling shows why engineering models must often represent time, feedback, uncertainty, and operating context together.

Back to top ↑

Verification, Validation, and Testing

Engineering modeling relies on verification and validation. Verification asks whether the model was implemented correctly. Validation asks whether the model is adequate for its intended real-world use. Testing provides evidence through experiments, prototypes, field data, inspections, and operational monitoring.

These are not bureaucratic extras. They are how engineering models earn trust.

Validation should be tied to purpose. A model validated for preliminary sizing is not necessarily validated for safety certification, field deployment, or automated control.

Back to top ↑

Uncertainty, Reliability, and Robustness

Engineering models operate under uncertainty. Loads vary. Material properties vary. Manufacturing introduces tolerances. Environments change. Users behave unpredictably. Sensors fail. Components age. Maintenance can be delayed. Models must therefore support reliability and robustness, not only nominal performance.

Robust engineering models ask whether a design remains acceptable across plausible variation, not only whether it succeeds in an idealized baseline case.

Back to top ↑

Major Model Families in Engineering

Engineering uses many model families. The right model depends on design stage, physical domain, available data, acceptable uncertainty, regulatory context, and consequence of failure.

No model family is universally best. Engineering modeling requires matching model form to design purpose, required evidence, and acceptable risk.

Back to top ↑

Disciplinary Examples

Mathematical modeling appears across engineering disciplines. The forms differ, but the shared purpose is to make design and performance reasoning explicit enough to test, compare, improve, and govern.

Across fields, engineering models help connect technical feasibility to safety, reliability, cost, and consequence.

Back to top ↑

Mathematical Lens: Engineering Models as Design-Constrained Representations

An engineering model often maps design variables, inputs, parameters, and assumptions into performance outputs:

Engineering design often requires satisfying constraints:

Optimization selects a design according to an objective and constraints:

A safety margin compares capacity against demand:

A reliability-oriented expression asks whether demand exceeds capacity:

The mathematical lesson is that engineering models are not only descriptions. They are constrained representations used to evaluate whether designs are feasible, safe, reliable, and fit for purpose.

Back to top ↑

Example: Beam Design Under Load and Safety Constraints

A simple beam design example shows how engineering modeling connects physical law, design variables, constraints, and safety margins. Suppose a beam must carry a load without exceeding an allowable stress. A simplified bending-stress model may estimate maximum stress as:

The design is acceptable only if stress remains below allowable stress:

The model is useful because it connects design geometry to safety-relevant performance. But it remains conditional. A complete engineering review may also require buckling, fatigue, deflection, vibration, connection design, manufacturing tolerance, environmental exposure, and applicable design codes.

Back to top ↑

Models, Prototypes, and Engineering Decision Support

Engineering models support decisions throughout the design lifecycle. Early models help frame feasibility. Detailed simulations support design comparison. Prototypes and tests validate assumptions. Operational models support monitoring and maintenance.

The relationship between model and prototype is not one-way. Models inform prototypes, and prototypes challenge models. Testing can reveal missing mechanisms, incorrect assumptions, unexpected failure modes, or real-world variability.

Engineering decision support is strongest when models, tests, prototypes, field observations, and governance records are connected rather than isolated.

Back to top ↑

Ethical Stakes of Engineering Modeling

Engineering models have ethical stakes because engineered systems affect safety, public infrastructure, environmental conditions, resource use, accessibility, health, privacy, and economic life. A model that underestimates risk can contribute to real harm.

Ethical engineering modeling requires transparency about assumptions, margins, validation, uncertainty, use limits, failure modes, affected stakeholders, and decision ownership. It also requires humility about what the model does not capture.

Engineering modeling is ethical when it supports safe design, honest communication, documented judgment, and accountable use.

Back to top ↑

Python Workflow: Engineering Design Register and Safety Review

The Python workflow below creates an engineering model register, evaluates beam design alternatives, computes simplified stress margins, flags designs that fail safety constraints, and writes an engineering design review card.

# mathematical_modeling_in_engineering_workflow.py
# Dependency-light workflow for engineering design and safety review.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
import statistics


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
OUTPUTS = ARTICLE_ROOT / "outputs"
TABLES = OUTPUTS / "tables"
JSON_DIR = OUTPUTS / "json"


@dataclass(frozen=True)
class EngineeringModelRecord:
    key: str
    engineering_domain: str
    model_role: str
    model_family: str
    design_question: str
    status: str


@dataclass(frozen=True)
class BeamDesign:
    key: str
    width_m: float
    height_m: float
    span_m: float
    load_n: float
    allowable_stress_pa: float
    material_density_kg_m3: float


def engineering_model_register() -> list[EngineeringModelRecord]:
    return [
        EngineeringModelRecord(
            key="sizing_model",
            engineering_domain="structural_engineering",
            model_role="initial_design",
            model_family="algebraic_design_model",
            design_question="What beam dimensions are feasible under baseline load?",
            status="active",
        ),
        EngineeringModelRecord(
            key="safety_model",
            engineering_domain="structural_engineering",
            model_role="safety_review",
            model_family="limit_state_model",
            design_question="Does the design maintain positive stress margin?",
            status="review",
        ),
        EngineeringModelRecord(
            key="optimization_model",
            engineering_domain="engineering_design",
            model_role="tradeoff_analysis",
            model_family="constrained_optimization",
            design_question="Which design balances weight and safety margin?",
            status="review",
        ),
        EngineeringModelRecord(
            key="uncertainty_model",
            engineering_domain="reliability_engineering",
            model_role="uncertainty_review",
            model_family="sensitivity_analysis",
            design_question="Which assumptions most affect safety margin?",
            status="review",
        ),
        EngineeringModelRecord(
            key="validation_model",
            engineering_domain="engineering_testing",
            model_role="validation",
            model_family="test_comparison",
            design_question="What test evidence is needed before use?",
            status="review",
        ),
    ]


def beam_designs() -> list[BeamDesign]:
    return [
        BeamDesign("light_design", 0.08, 0.16, 3.0, 4200.0, 145_000_000.0, 7850.0),
        BeamDesign("balanced_design", 0.10, 0.18, 3.0, 4200.0, 145_000_000.0, 7850.0),
        BeamDesign("stiff_design", 0.12, 0.22, 3.0, 4200.0, 145_000_000.0, 7850.0),
        BeamDesign("overloaded_case", 0.10, 0.18, 3.0, 7000.0, 145_000_000.0, 7850.0),
    ]


def evaluate_beam(design: BeamDesign) -> dict[str, object]:
    # Simple center-point load model for a simply supported beam:
    # max bending moment M = P L / 4.
    # Rectangular section: I = b h^3 / 12, c = h / 2.
    moment = design.load_n * design.span_m / 4.0
    inertia = design.width_m * design.height_m**3 / 12.0
    c = design.height_m / 2.0
    stress = moment * c / inertia
    margin = design.allowable_stress_pa - stress
    safety_factor = design.allowable_stress_pa / stress if stress > 0 else float("inf")
    volume = design.width_m * design.height_m * design.span_m
    mass = volume * design.material_density_kg_m3

    return {
        **asdict(design),
        "bending_moment_nm": round(moment, 8),
        "second_moment_area_m4": round(inertia, 12),
        "max_stress_pa": round(stress, 8),
        "stress_margin_pa": round(margin, 8),
        "safety_factor": round(safety_factor, 8),
        "estimated_mass_kg": round(mass, 8),
        "passes_stress_constraint": stress <= design.allowable_stress_pa,
        "review_class": "acceptable" if stress <= design.allowable_stress_pa else "fails_constraint",
    }


def engineering_priority(record: EngineeringModelRecord) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.model_role} {record.model_family} {record.design_question}".lower()
    for term in ["safety", "validation", "uncertainty", "constraint", "optimization", "margin"]:
        if term in text:
            score += 1.0
    return round(score, 3)


def design_summary(rows: list[dict[str, object]]) -> dict[str, object]:
    safety_factors = [float(row["safety_factor"]) for row in rows]
    masses = [float(row["estimated_mass_kg"]) for row in rows]
    failures = sum(1 for row in rows if not bool(row["passes_stress_constraint"]))
    acceptable_rows = [row for row in rows if bool(row["passes_stress_constraint"])]
    lightest_acceptable = min(acceptable_rows, key=lambda row: float(row["estimated_mass_kg"])) if acceptable_rows else None

    return {
        "mean_safety_factor": round(statistics.mean(safety_factors), 8),
        "min_safety_factor": round(min(safety_factors), 8),
        "max_safety_factor": round(max(safety_factors), 8),
        "mean_mass_kg": round(statistics.mean(masses), 8),
        "failed_design_count": failures,
        "design_count": len(rows),
        "lightest_acceptable_design": None if lightest_acceptable is None else lightest_acceptable["key"],
    }


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows supplied for {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", encoding="utf-8") as handle:
        json.dump(payload, handle, indent=2, sort_keys=True)


def main() -> None:
    records = engineering_model_register()
    designs = beam_designs()

    register_rows = [
        {**asdict(record), "engineering_priority": engineering_priority(record)}
        for record in records
    ]

    design_rows = [evaluate_beam(design) for design in designs]

    write_csv(TABLES / "engineering_model_register.csv", register_rows)
    write_csv(TABLES / "beam_design_review.csv", design_rows)

    write_json(JSON_DIR / "engineering_design_review_card.json", {
        "article": "Mathematical Modeling in Engineering",
        "design_summary": design_summary(design_rows),
        "engineering_model_register": register_rows,
        "beam_design_review": design_rows,
        "use_limit": "This simplified beam workflow is illustrative and does not replace engineering standards, professional review, detailed structural analysis, or applicable design codes.",
        "diagnostic_checks": [
            "requirements and constraints are stated",
            "stress margin is computed",
            "failed designs are flagged",
            "tradeoff between mass and safety is visible",
            "validation evidence is required before use",
            "use limits are stated explicitly",
        ],
    })

    print("Engineering modeling workflow complete.")
    print(f"Design summary: {design_summary(design_rows)}")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow treats engineering modeling as design evidence. It records model purpose, design constraints, stress margins, safety factors, failed alternatives, tradeoffs, validation needs, and use limits.

Back to top ↑

R Workflow: Design Alternative Summary and Safety Review

The R workflow below reviews generated engineering outputs, ranks designs by safety factor and mass, summarizes failed designs, and creates a base R safety-factor plot.

# mathematical_modeling_in_engineering_review.R
# Base R workflow for engineering design and safety review.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

register_path <- file.path(tables_dir, "engineering_model_register.csv")
design_path <- file.path(tables_dir, "beam_design_review.csv")

if (!file.exists(register_path) || !file.exists(design_path)) {
  stop("Missing engineering modeling outputs. Run the Python workflow first.")
}

register <- read.csv(register_path, stringsAsFactors = FALSE)
designs <- read.csv(design_path, stringsAsFactors = FALSE)

register$engineering_priority <- as.numeric(register$engineering_priority)
designs$safety_factor <- as.numeric(designs$safety_factor)
designs$estimated_mass_kg <- as.numeric(designs$estimated_mass_kg)
designs$max_stress_pa <- as.numeric(designs$max_stress_pa)
designs$stress_margin_pa <- as.numeric(designs$stress_margin_pa)

register <- register[order(-register$engineering_priority), ]
designs <- designs[order(-designs$safety_factor), ]

summary_table <- data.frame(
  mean_safety_factor = mean(designs$safety_factor),
  min_safety_factor = min(designs$safety_factor),
  max_safety_factor = max(designs$safety_factor),
  failed_design_count = sum(designs$passes_stress_constraint == "False" | designs$passes_stress_constraint == FALSE),
  design_count = nrow(designs)
)

write.csv(
  register,
  file.path(tables_dir, "r_engineering_model_review_queue.csv"),
  row.names = FALSE
)

write.csv(
  designs,
  file.path(tables_dir, "r_beam_design_ranking.csv"),
  row.names = FALSE
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_engineering_design_summary.csv"),
  row.names = FALSE
)

png(file.path(figures_dir, "r_beam_safety_factors.png"), width = 1000, height = 700)

barplot(
  designs$safety_factor,
  names.arg = designs$key,
  las = 2,
  ylab = "Safety factor",
  main = "Beam Design Safety Factors"
)

dev.off()

print(register)
print(summary_table)
print(designs)

The R layer supports engineering review by preserving model priorities, design rankings, safety factors, failed constraints, and summary diagnostics.

Back to top ↑

Haskell Workflow: Typed Engineering Model Records

Haskell is useful here because engineering model categories should remain distinct. A sizing model is not a validation model. Optimization is not safety certification. Simulation is not physical testing. A use limit is not a design requirement.

{-# OPTIONS_GHC -Wall #-}

module Main where

data EngineeringDomain
  = StructuralEngineering
  | MechanicalEngineering
  | ElectricalEngineering
  | ChemicalEngineering
  | SystemsEngineering
  | ReliabilityEngineering
  deriving (Eq, Show)

data EngineeringModelRole
  = InitialDesign
  | PerformanceAnalysis
  | SafetyReview
  | Optimization
  | Validation
  | LifecycleMonitoring
  deriving (Eq, Show)

data EngineeringModelFamily
  = AlgebraicDesignModel
  | DifferentialEquationModel
  | FiniteElementModel
  | ControlModel
  | ReliabilityModel
  | SimulationModel
  deriving (Eq, Show)

data ReviewStatus
  = Active
  | RequiresReview
  | RequiresValidation
  | RequiresSafetyReview
  | Revise
  deriving (Eq, Show)

data EngineeringModelRecord = EngineeringModelRecord
  { key :: String
  , domain :: EngineeringDomain
  , role :: EngineeringModelRole
  , family :: EngineeringModelFamily
  , designQuestion :: String
  , status :: ReviewStatus
  } deriving (Eq, Show)

engineeringRegister :: [EngineeringModelRecord]
engineeringRegister =
  [ EngineeringModelRecord
      "sizing_model"
      StructuralEngineering
      InitialDesign
      AlgebraicDesignModel
      "What beam dimensions are feasible under baseline load?"
      Active
  , EngineeringModelRecord
      "safety_model"
      StructuralEngineering
      SafetyReview
      AlgebraicDesignModel
      "Does the design maintain positive stress margin?"
      RequiresSafetyReview
  , EngineeringModelRecord
      "optimization_model"
      SystemsEngineering
      Optimization
      SimulationModel
      "Which design balances weight and safety margin?"
      RequiresReview
  , EngineeringModelRecord
      "validation_model"
      ReliabilityEngineering
      Validation
      ReliabilityModel
      "What test evidence is needed before use?"
      RequiresValidation
  ]

needsReview :: EngineeringModelRecord -> Bool
needsReview item =
  case status item of
    Active -> False
    _ -> True

main :: IO ()
main = do
  putStrLn "Typed engineering model records:"
  mapM_ print engineeringRegister

  putStrLn "\nEngineering model records requiring review:"
  mapM_ print (filter needsReview engineeringRegister)

This typed layer supports engineering model governance by keeping domains, roles, model families, design questions, and review obligations distinct.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It contains article-specific code, data, documentation, notebooks, schemas, and generated outputs for engineering model registers, beam design review, stress-margin analysis, design-alternative comparison, safety-factor summaries, typed Haskell engineering records, and responsible engineering modeling workflows.

Back to top ↑

A Practical Method for Mathematical Modeling in Engineering

Engineering modeling should be structured enough to support review, testing, revision, and accountability. The goal is not only to compute a result, but to show why a design is believed to be feasible, safe, and fit for purpose.

This method keeps engineering models tied to design responsibility. It prevents calculations from being detached from requirements, constraints, safety margins, validation, and consequences.

Back to top ↑

Common Pitfalls

Engineering modeling can fail when formal analysis is treated as stronger than the assumptions, evidence, and validation behind it. Many failures come from overconfidence, not from modeling itself.

• Unclear requirements: building a technically detailed model without clear design criteria.
• Baseline-only modeling: testing ordinary conditions while ignoring peak, adverse, or failure cases.
• Hidden safety assumptions: using margins or factors without documenting their rationale.
• Optimization without consequence review: minimizing cost, mass, or energy while increasing risk elsewhere.
• Simulation overconfidence: treating digital output as validated reality.
• Weak validation: calibrating or fitting a model but not testing it against independent evidence.
• Ignoring tolerances: assuming manufactured components match ideal geometry exactly.
• Missing failure modes: modeling expected performance while omitting fatigue, buckling, wear, overheating, instability, or cascading effects.
• No lifecycle thinking: ignoring aging, maintenance, degradation, and operational drift.
• No use-limit statement: allowing the model to be applied beyond its design context or validation domain.

These pitfalls can be reduced through clear requirements, failure-mode review, uncertainty analysis, design alternatives, validation, reproducible workflows, and explicit use limits.

Back to top ↑

Conclusion: Engineering Models Turn Formal Reasoning Into Responsible Design

Mathematical modeling is central to engineering because it turns formal reasoning into design evidence. It helps engineers connect requirements, physics, materials, constraints, simulations, safety margins, optimization, uncertainty, and testing into a coherent design process.

But engineering models do not replace engineering judgment. They depend on assumptions, data, simplifications, material properties, boundary conditions, validation evidence, and use context. Their authority comes from disciplined review, not from calculation alone.

A strong engineering model makes design reasoning inspectable. It shows what the system is expected to do, what could go wrong, how much margin exists, which tradeoffs were accepted, and what evidence is needed before use.

Used responsibly, mathematical modeling helps engineering move from concept to safe implementation without pretending that uncertainty, failure, or accountability have disappeared.

Back to top ↑

Related Articles

• What Is Mathematical Modeling?
• Model Purpose: Explanation, Prediction, Control, and Decision Support
• Variables, Parameters, and Constraints
• Optimization Models and Objective Functions
• Simulation and Computational Modeling
• Numerical Methods for Mathematical Models
• Validation and Model Assessment
• Uncertainty in Mathematical Models
• Mathematical Modeling in Science
• Mathematical Modeling in Policy and Public Systems

Back to top ↑

Further Reading

• Blanchard, B.S. and Fabrycky, W.J. (2011) Systems Engineering and Analysis. 5th edn. Upper Saddle River, NJ: Prentice Hall.
• Dieter, G.E. and Schmidt, L.C. (2013) Engineering Design. 5th edn. New York: McGraw-Hill.
• Fishman, G.S. (2001) Discrete-Event Simulation: Modeling, Programming, and Analysis. New York: Springer.
• Haimes, Y.Y. (2016) Risk Modeling, Assessment, and Management. 4th edn. Hoboken, NJ: Wiley.
• Hibbeler, R.C. (2017) Mechanics of Materials. 10th edn. Boston: Pearson.
• INCOSE (2015) Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. 4th edn. Hoboken, NJ: Wiley.
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press.
• Pahl, G., Beitz, W., Feldhusen, J. and Grote, K.H. (2007) Engineering Design: A Systematic Approach. 3rd edn. London: Springer.
• Saltelli, A. et al. (2008) Global Sensitivity Analysis: The Primer. Chichester: Wiley.
• Ulrich, K.T. and Eppinger, S.D. (2016) Product Design and Development. 6th edn. New York: McGraw-Hill Education.

Back to top ↑

References

• Blanchard, B.S. and Fabrycky, W.J. (2011) Systems Engineering and Analysis. 5th edn. Upper Saddle River, NJ: Prentice Hall.
• Dieter, G.E. and Schmidt, L.C. (2013) Engineering Design. 5th edn. New York: McGraw-Hill.
• Fishman, G.S. (2001) Discrete-Event Simulation: Modeling, Programming, and Analysis. New York: Springer.
• Haimes, Y.Y. (2016) Risk Modeling, Assessment, and Management. 4th edn. Hoboken, NJ: Wiley.
• Hibbeler, R.C. (2017) Mechanics of Materials. 10th edn. Boston: Pearson.
• INCOSE (2015) Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. 4th edn. Hoboken, NJ: Wiley.
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press.
• Pahl, G., Beitz, W., Feldhusen, J. and Grote, K.H. (2007) Engineering Design: A Systematic Approach. 3rd edn. London: Springer.
• Saltelli, A. et al. (2008) Global Sensitivity Analysis: The Primer. Chichester: Wiley.
• Ulrich, K.T. and Eppinger, S.D. (2016) Product Design and Development. 6th edn. New York: McGraw-Hill Education.

Back to top ↑