Understanding What In Engineering Fundamentals And Applications

Published

Table of Contents

Engineering is fundamentally rooted in addressing the what—the core objectives, constraints, and problems that drive innovation across disciplines. Unlike scientific inquiry, which often explores how or why, engineering prioritizes defining the what as the foundation for every solution, from structural integrity in bridges to sustainable energy systems. This distinction shapes not only technical specifications but also ethical, societal, and historical dimensions, where misalignment in defining the what can lead to systemic failures or transformative breakthroughs.

The exploration of what in engineering spans theoretical frameworks, problem-solving methodologies, and practical tools that engineers employ to translate abstract goals into tangible outcomes. Whether through structured design briefs, computational simulations, or regulatory compliance, the what serves as the compass guiding engineers from conceptualization to execution. By examining real-world case studies—such as the Panama Canal’s logistical challenges or modern AI-driven infrastructure—this discussion reveals how the definition of what evolves with technological and societal progress, ensuring relevance in an ever-changing landscape.

what in engineering

Fundamental Principles Defining "What" in Engineering

Engineering disciplines are rooted in addressing the "what"—the identification, quantification, and systematic understanding of physical phenomena, constraints, and objectives that underpin functional systems. Unlike scientific inquiry, which often explores "how" or "why" natural processes occur, engineering prioritizes the "what" to solve real-world problems through applied mathematics, empirical data, and design principles. This distinction ensures that engineering solutions are both theoretically sound and practically viable, bridging abstract theory with tangible outcomes.

The core of engineering lies in translating abstract questions—such as "what forces act on a structure?", "what energy transformations occur in a heat engine?", or "what material properties enable durability?"—into actionable design parameters. These questions form the bedrock of disciplines ranging from structural mechanics to thermal systems, where the objective is not merely explanation but the creation of systems that meet specified performance criteria.

Structured Comparison of Engineering Disciplines and Their Core "What" Objectives

Engineering disciplines vary in their primary focus, yet all converge on defining the "what"—the fundamental variables, constraints, or phenomena that must be quantified to achieve a functional design. Below is a comparative table illustrating key disciplines, their focus areas, core objectives, and example applications.
Discipline Key Focus Core "What" (Objective/Goal) Example Application
Mechanical Engineering Forces, motion, energy, and material behavior under load Determine the what forces, stresses, and deformations act on components to ensure structural integrity and dynamic performance. Design of automotive suspension systems (analyzing load distribution and vibration damping).
Thermodynamics (Thermal Engineering) Energy transfer, heat, work, and fluid flow Quantify the what energy transformations and efficiencies occur in systems to optimize performance and sustainability. Development of combined-cycle power plants (maximizing thermal efficiency via heat recovery).
Materials Science Microstructure, properties, and performance of materials Identify the what material properties (e.g., strength, conductivity, corrosion resistance) are required for a given application. Selection of titanium alloys for aerospace components (balancing weight, strength, and thermal stability).
Electrical Engineering Electromagnetic fields, circuits, and signal processing Define the what voltage, current, and impedance characteristics govern system behavior to ensure reliability and functionality. Design of high-voltage transmission lines (minimizing power loss via conductor material and spacing).
Civil Engineering Structural stability, geotechnics, and environmental interactions Assess the what loads (static/dynamic), soil conditions, and environmental factors influence construction safety and longevity. Construction of earthquake-resistant bridges (incorporating seismic load analysis).
Chemical Engineering Reaction kinetics, mass/energy balances, and process optimization Determine the what reaction rates, phase equilibria, and thermodynamic constraints dictate process efficiency. Design of catalytic converters (optimizing pollutant conversion via reaction conditions).
The table highlights that the "what" in engineering is discipline-specific yet universally tied to quantifiable parameters that dictate design feasibility. For instance, in mechanical engineering, the "what" revolves around forces and motion, while in thermodynamics, it centers on energy conservation and transfer. This specificity ensures that engineering problems are framed around measurable variables, distinguishing them from philosophical or purely theoretical inquiries.

Translation of "What" Questions into Engineering Problem Statements

The engineering approach to "what" questions transforms abstract inquiries into structured problem statements that guide analysis, modeling, and design. Below are examples illustrating how general "what" questions are decomposed into engineering-specific objectives:

1. Structural Mechanics

  • General Question: "What forces act on a bridge?"
  • Engineering Translation: "Determine the magnitude, direction, and distribution of static and dynamic loads (e.g., dead loads, wind loads, seismic forces) on a bridge deck and support structures to ensure compliance with safety codes (e.g., AASHTO LRFD)."
  • Key Parameters: Shear forces, bending moments, stress concentrations, and deflection limits.

    • 2. Thermodynamics

  • General Question: "What happens to energy in a heat engine?"
  • Engineering Translation: "Quantify the energy input (Q_in), work output (W_out), and losses (Q_out) in a Rankine cycle to calculate thermal efficiency (η = W_out / Q_in) and identify opportunities for waste heat recovery."
  • Key Parameters: Carnot efficiency limits, pressure-enthalpy diagrams, and exergy analysis.

    • 3. Materials Science

  • General Question: "What makes a material strong?"
  • Engineering Translation: "Evaluate the microstructural features (grain size, dislocation density), mechanical properties (yield strength, toughness), and environmental interactions (corrosion, fatigue) to select or design a material for a specific application (e.g., high-strength steel for pressure vessels)."
  • Key Parameters: Ultimate tensile strength (UTS), fracture toughness (K_IC), and creep resistance.

    • 4. Fluid Dynamics

  • General Question: "What affects fluid flow in a pipe?"
  • Engineering Translation: "Analyze the Reynolds number (Re), pressure drop (ΔP), and boundary layer characteristics to optimize pipe diameter, roughness, and flow regime (laminar/turbulent) for minimal energy loss."
  • Key Parameters: Darcy-Weisbach equation, friction factor (f), and velocity profiles.

    • The distinction between engineering "what" questions and scientific "how" or philosophical "why" inquiries lies in their practical orientation. Engineering "what" questions are actionable, focusing on quantifiable variables that directly inform design decisions. In contrast, scientific "how" questions explore mechanisms (e.g., "How does turbulence form?"), while philosophical "why" questions probe purpose or ethics (e.g., "Why should we prioritize sustainability?").

    Engineering "what" questions are problem-centric, whereas scientific "how" questions are mechanism-centric. The former seeks to define constraints and objectives for design, while the latter seeks to explain underlying processes. This divergence ensures engineering remains solution-oriented, even as it relies on scientific principles for validation.

    Engineering Problem-Solving Frameworks: Structuring the "What" Before the "How"

    Engineering problem-solving begins with a rigorous definition of the problem’s core components—requirements, constraints, variables, and objectives—before transitioning to solution design. This foundational phase ensures alignment between stakeholder expectations and technical feasibility, reducing iterative revisions and resource waste. Methodologies such as systems engineering and design thinking formalize this decomposition, emphasizing iterative validation of the "what" to mitigate ambiguity. Real-world failures, including the Mars Climate Orbiter (1999) and the London Millennium Bridge (2000), underscore how misdefining the "what" can lead to catastrophic consequences, often due to overlooked units, load assumptions, or stakeholder misalignment.

    Decomposition of Engineering Problems into "What" Components

    The decomposition process breaks down a problem into discrete, analyzable elements by categorizing them into requirements, constraints, variables, and objectives. Requirements define functional and non-functional needs (e.g., performance metrics, usability standards), while constraints impose limitations (e.g., budget, material properties, regulatory compliance). Variables represent measurable parameters (e.g., temperature, pressure, dimensions) that influence outcomes, and objectives quantify success criteria (e.g., efficiency, reliability, cost reduction).

    Engineers employ structured frameworks to map these components:

  • Functional Decomposition: Divides the problem into subsystems or modules (e.g., mechanical, electrical, software) to isolate dependencies.
  • Parameter Space Definition: Identifies independent and dependent variables (e.g., input/output relationships in control systems).
  • Hierarchical Modeling: Uses abstraction layers (e.g., system-level, subsystem-level, component-level) to manage complexity.
    • Key Principle:
    "A problem well-defined is half-solved." — Attributed to early systems engineering practitioners.
    This emphasizes that ambiguity in the "what" phase propagates into solution inefficiencies, rework, or failure.

    Step-by-Step Procedure for Problem Decomposition

    The following structured approach ensures systematic identification of the "what" before addressing the "how." Each step builds on prior analysis to validate assumptions and refine scope.

    1. Problem Statement Clarification

  • Objective: Translate vague descriptions into measurable terms.
  • Actions:
  • Engage stakeholders (clients, end-users, regulators) to define needs (e.g., "reduce energy consumption by 20%" vs. "improve efficiency").
  • Document boundaries (e.g., operational environment, lifecycle stages).
  • Use SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound) to refine objectives.
  • Example: A smart thermostat project must clarify whether "energy savings" refers to peak demand reduction or annual consumption.

    • 2. Requirements Elicitation and Classification

  • Objective: Differentiate between functional (what the system must do) and non-functional (how it must perform) requirements.
  • Actions:
  • Use MoSCoW prioritization (Must-have, Should-have, Could-have, Won’t-have) to rank requirements.
  • Apply Kano Model to categorize requirements by customer satisfaction impact (basic, performance, excitement).
  • Validate with prototype sketches or use-case diagrams to test feasibility.
  • Example: An autonomous vehicle must prioritize safety-critical requirements (e.g., collision avoidance) over desirability features (e.g., infotainment).

    • 3. Constraint Identification and Trade-off Analysis

  • Objective: Quantify limitations that shape feasible solutions.
  • Actions:
  • Categorize constraints into hard (non-negotiable, e.g., material strength) and soft (negotiable, e.g., cost targets).
  • Perform trade-off matrices to evaluate alternatives (e.g., weight vs. strength in aerospace components).
  • Use Pareto analysis to identify critical constraints (e.g., 80% of project delays stem from 20% of unresolved constraints).
  • Example: The Boeing 787 Dreamliner’s composite materials reduced weight but introduced manufacturing constraints (e.g., autoclave cycle times), requiring redefined assembly processes.

    • 4. Variable and Parameter Space Definition

  • Objective: Define measurable inputs, outputs, and their relationships.
  • Actions:
  • Create input-output models (e.g., control systems block diagrams) to map variables.
  • Apply dimensional analysis to ensure unit consistency (a root cause of the Mars Climate Orbiter failure).
  • Use sensitivity analysis to identify variables with high impact on outcomes.
  • Example: In HVAC design, variable air volume (VAV) systems require precise definition of airflow rates (CFM) and temperature setpoints (°C) to avoid energy inefficiencies.

    • 5. Validation and Iterative Refinement

  • Objective: Ensure the "what" is unambiguous and feasible.
  • Actions:
  • Conduct requirements reviews with stakeholders to resolve ambiguities.
  • Perform gap analysis between current state and desired state (e.g., benchmarking against industry standards).
  • Use prototyping (physical or digital) to test assumptions (e.g., 3D-printed components for fit/stress validation).
  • Example: The F-35 Joint Strike Fighter faced delays due to misaligned requirements between the U.S., UK, and Italian stakeholders, requiring iterative refinement of stealth and payload specifications.

    • Flowchart-Style Outline: Identifying the "What" Before the "How"

    The following hierarchical outline visualizes the decision flow for defining the "what" in engineering problems, emphasizing iterative validation before solution design.

    Problem Identification
    │
    ├── Stakeholder Engagement → Define needs, boundaries, and success criteria.
    │ │
    │ ├── Clarify Objectives (SMART criteria)
    │ └── Document Assumptions (e.g., environmental conditions)
    │
    ├── Requirements Analysis
    │ │
    │ ├── Classify Requirements (functional vs. non-functional)
    │ ├── Prioritize (MoSCoW/Kano Model)
    │ └── Validate Feasibility (prototypes, use cases)
    │
    ├── Constraint Mapping
    │ │
    │ ├── Categorize (hard vs. soft)
    │ ├── Trade-off Analysis (weight vs. cost, performance vs. safety)
    │ └── Risk Assessment (failure modes, mitigation strategies)
    │
    ├── Variable Definition
    │ │
    │ ├── Input-Output Modeling (system dynamics, control theory)
    │ ├── Unit Consistency Check (dimensional analysis)
    │ └── Sensitivity Analysis (identify critical parameters)
    │
    └── Iterative Refinement
    │
    ├── Gap Analysis (vs. benchmarks/standards)
    ├── Prototyping (physical/digital validation)
    └── Stakeholder Sign-off (requirements baseline)

    Key Decision Points:

  • Loop Backs: If constraints or variables are redefined, revisit requirements and objectives.
  • Termination Condition: Achieved when all stakeholders agree on a baselined "what" (documented in a System Requirements Specification or equivalent).

    • Methodologies Prioritizing the "What" Phase

    Several engineering and design methodologies formalize the "what" phase to minimize ambiguity and misalignment. These approaches are adopted across industries, from aerospace to software development.

    1. Systems Engineering (SE)

  • Core Principle: "Define the system before designing its components."
  • Key Practices:
  • INCOSE Systems Engineering Handbook: Advocates for V-model development, where requirements cascade from system-level to subsystem-level.
  • Vee Diagram: Visualizes the relationship between requirements decomposition (left side) and verification/testing (right side).
  • System Context Diagrams: Map interactions between the system and external entities (e.g., users, other systems).
  • Example: NASA’s James Webb Space Telescope used SE to define optical, thermal, and mechanical requirements before fabrication, avoiding the Hubble Telescope’s spherical aberration error (misdefined mirror specifications).

    • 2. Design Thinking

  • Core Principle: "Empathize, define, ideate, prototype, test" (IDEO’s framework).
  • Relevance to "What":
  • Empathize: Identify user needs through interviews and observations (e.g., medical device design for elderly patients).
  • Define: Craft a point of view (POV) statement (e.g., "How might we reduce patient recovery time by 30% for post-surgical patients?").
  • Prototyping: Low-fidelity models (e.g., paper sketches, 3D-printed mockups) validate feasibility before high-cost development.
  • Example: IDEO’s redesign of the Stanford Hospital’s emergency department prioritized defining patient flow constraints before introducing new

    • what in engineering - Ilustrasi 2

    Technical Specifications and Defining "What" in Engineering Design

    Engineering projects thrive on clarity, and technical specifications serve as the foundational framework that explicitly or implicitly articulates the "what"—the core requirements, constraints, and objectives before delving into the "how" of implementation. These specifications, ranging from standardized industrial norms (e.g., ISO, ANSI) to project-specific design briefs, ensure alignment between stakeholders, mitigate ambiguity, and establish measurable criteria for success. Without precise definitions of "what," even the most innovative solutions risk misalignment with user needs, regulatory demands, or operational feasibility. This section examines how specifications structure the design problem, identifies common ambiguities, and provides actionable templates for drafting unambiguous "what" statements.

    Classification of Engineering Specifications and Their Role in Defining "What"

    Technical specifications vary in formality, scope, and applicability, yet all contribute to defining the "what" by establishing boundaries, performance thresholds, and stakeholder expectations. Below is a structured comparison of specification types, their examples, and their impact on design clarity, alongside potential ambiguities that may arise if not carefully managed.
    Specification Type Example How It Defines "What" Potential Ambiguities
    Regulatory Standards(e.g., ISO, ASTM, IEC)
    • ISO 9001 (Quality Management)
    • ASTM A36 (Structural Steel Properties)
    • IEC 61508 (Functional Safety)

    Establishes mandatory or recommended criteria for safety, performance, and interoperability. These specifications act as non-negotiable constraints, ensuring compliance with industry or legal requirements. For instance, ISO 9001 defines quality management processes that must be adhered to, while ASTM A36 specifies material properties for steel used in construction.

    Version discrepancies (e.g., outdated standards), regional variations in interpretation, or gaps between standard requirements and project-specific needs. For example, a standard may specify a minimum yield strength for steel but not address corrosion resistance in coastal environments.
    Design Briefs/Project Charters
    • Skyscraper: "Design a 50-story mixed-use building in Dubai with a minimum 200m height, LEED Gold certification, and seismic resistance for Category 4 zones."
    • Medical Device: "Develop a portable glucose monitor with <10% accuracy error, 5-minute response time, and FDA Class II compliance."

    Articulates the high-level objectives, constraints, and success metrics for a project. These documents bridge stakeholder expectations (e.g., clients, end-users) with technical feasibility. For example, a design brief for a bridge might specify load-bearing capacity, aesthetic preferences, and budget, while a medical device brief prioritizes clinical efficacy and regulatory hurdles.

    Vague language (e.g., "user-friendly" without quantifiable metrics), conflicting priorities among stakeholders, or omission of critical constraints (e.g., environmental impact assessments). A brief stating "minimal maintenance" without defining a timeframe or cost threshold leaves room for interpretation.
    Performance Specifications
    • Automotive: "Engine efficiency > 35% at 2,500 RPM with <5% variation over 100,000 miles."
    • Renewable Energy: "Solar panel efficiency ≥ 22% under STC (Standard Test Conditions)."

    Focuses on measurable outcomes rather than prescriptive solutions. These define the "what" by setting functional targets (e.g., efficiency, durability, response time) that solutions must meet. For example, a performance spec for a drone might require a 30-minute flight time with a 5kg payload, leaving the battery technology or propulsion method open to innovation.

    Lack of context for test conditions (e.g., "efficiency" without specifying temperature or humidity), trade-off ambiguities (e.g., prioritizing cost over performance), or unrealistic benchmarks based on theoretical limits rather than practical feasibility.
    Interface Specifications
    • Software-Hardware: "USB 3.2 Gen 2×2 interface with 20Gbps data transfer rate and backward compatibility to USB 2.0."
    • Mechanical: "Flange connection for 10-inch pipes with ANSI B16.5 Class 300 rating."

    Defines how components or systems interact, ensuring compatibility and interoperability. These specifications clarify the "what" by prescribing communication protocols, physical dimensions, or signal formats. For instance, an interface spec for a robot arm might dictate torque limits, repeatability tolerances, and control signal types to integrate with a factory automation system.

    Incomplete documentation of edge cases (e.g., error handling in data transfer), proprietary dependencies (e.g., vendor-specific protocols), or lack of future-proofing (e.g., no consideration for scalability).
    Sustainability and Ethical Constraints
    • Building: "Net-zero carbon emissions by 2030, achieved through 50% on-site renewable energy and 30% recycled materials by mass."
    • Agricultural: "Precision irrigation system reducing water usage by 40% with <10% crop yield loss."

    Incorporates non-technical but critical constraints such as environmental impact, social responsibility, or ethical considerations. These redefine the "what" by introducing qualitative or systemic objectives. For example, a sustainability spec for a data center might require 100% renewable energy sourcing and a "circular economy" design principle for end-of-life disposal.

    Subjectivity in metrics (e.g., "ethical sourcing" without supply chain audits), conflicting sustainability goals (e.g., cost vs. carbon footprint), or lack of standardized frameworks for verification (e.g., varying definitions of "green" across regions).

    The table highlights that while specifications provide clarity, their effectiveness hinges on precision in language, alignment with stakeholder priorities, and proactive identification of ambiguities. For instance, a performance specification for a battery might state "lifespan of 5 years," but without defining usage patterns (e.g., deep-cycle vs. shallow discharges), engineers may misinterpret the requirement.

    Template for Drafting a "What" Statement in Engineering Design

    A well-structured "what" statement serves as a single-source reference for all design decisions, ensuring consistency across multidisciplinary teams. Below is a template with placeholders for key elements, categorized by stakeholder, constraint, and objective. This template can be adapted for projects ranging from consumer electronics to infrastructure.
    Project "What" Statement Template

    1. Stakeholder Requirements

    • Primary Users: [Describe end-users, e.g., "pedestrians, commercial tenants, emergency responders"]
    • Secondary Stakeholders: [List others, e.g., "city planners, maintenance crews, regulatory bodies"]
    • Key Expectations: [Quantify or qualify needs, e.g., "95% user satisfaction in usability tests," "reduced commute time by 20%"]
    2. Functional Requirements
    • Core Functions: [List primary operations, e.g., "data acquisition," "structural

      Tools and Software for Defining Engineering "What"

      Engineering design begins with defining the what—the conceptual, functional, and performance requirements of a system before translating them into tangible solutions. Tools and software play a critical role in this phase by enabling engineers to model, simulate, and validate hypotheses without committing to physical prototypes. These tools bridge the gap between abstract ideas and actionable specifications, ensuring that the "what" is rigorously explored before implementation. Below are categorized tools, their applications, and a comparative analysis of their roles in different design stages, followed by a practical guide for parametric exploration.

      Categorization of Tools by Design Stage

      Tools for defining engineering "what" are selected based on the stage of the design process: conceptualization, analysis, simulation, and validation. Each stage demands specific functionalities, such as ideation support, mathematical modeling, or performance verification. The following table compares widely used tools across these stages, highlighting their strengths and typical use cases.
      Tool/Software Primary Stage Key Features Example Applications
      SolidWorks Conceptualization, Analysis
      • Parametric 3D modeling with design tables for scenario exploration.
      • Integrated finite element analysis (FEA) for stress/strain evaluation.
      • Assembly simulations to test kinematics and interference.
      • Sustainability metrics (e.g., material efficiency) for early-stage trade-offs.
      • Exploring geometric variations in a gearbox housing under different load conditions.
      • Optimizing a bracket design for weight reduction while maintaining stiffness.
      SysML (Systems Modeling Language) Conceptualization, Analysis, Validation
      • Diagrams for system architecture (e.g., block definition, use case, sequence).
      • Parametric constraints and requirements management.
      • Integration with MATLAB/Simulink for hybrid system modeling.
      • Model-based systems engineering (MBSE) for complex, multi-domain systems.
      • Defining functional requirements for an autonomous vehicle’s perception system.
      • Validating system-level interactions in a power grid design.
      MATLAB/Simulink Analysis, Simulation, Validation
      • Algorithmic modeling for control systems and signal processing.
      • Simulink for dynamic system simulation (e.g., PID tuning, motor behavior).
      • Optimization toolboxes (e.g., `fmincon`) for parametric studies.
      • Integration with hardware-in-the-loop (HIL) testing.
      • Simulating a battery management system’s response to charging cycles.
      • Testing a flight controller’s stability under turbulent conditions.
      ANSYS Analysis, Simulation, Validation
      • Multiphysics simulation (e.g., thermal-stress coupling, fluid-structure interaction).
      • Customizable parametric sweeps for sensitivity analysis.
      • CFD and electromagnetic solvers for specialized domains.
      • Automation via ACT scripting for repetitive "what-if" scenarios.
      • Evaluating heat dissipation in a CPU cooler under varying fan speeds.
      • Assessing electromagnetic interference in a PCB layout.
      CATIA Conceptualization, Analysis
      • Surface and solid modeling with generative design capabilities.
      • Kinematics and dynamic simulation for mechanical systems.
      • PLM (Product Lifecycle Management) integration for collaborative design.
      • Siemens’ "Generative Design" tool for topology optimization.
      • Generating optimal support structures for additive manufacturing.
      • Simulating the motion of a robotic arm with joint constraints.
      LabVIEW Simulation, Validation
      • Graphical programming for data acquisition and instrument control.
      • Real-time simulation of embedded systems (e.g., FPGA integration).
      • Customizable dashboards for monitoring "what-if" scenario outputs.
      • Integration with NI hardware for hardware-in-the-loop (HIL) testing.
      • Validating a sensor fusion algorithm in an autonomous drone.
      • Testing a PLC’s response to process variable changes in a chemical plant.
      Grasshopper (Rhino) Conceptualization, Analysis
      • Algorithmic design for parametric modeling in architecture/engineering.
      • Python/C# scripting for custom logic (e.g., optimization algorithms).
      • Visual programming for generative geometry.
      • Integration with Rhino’s NURBS modeling for complex shapes.
      • Generating lattice structures for lightweight aerospace components.
      • Exploring morphological variations in a bridge design.
      Key Considerations for Tool Selection:
      The choice of tool depends on the domain specificity (e.g., mechanical vs. electrical), complexity of interactions (single-physics vs. multiphysics), and collaboration requirements (e.g., SysML for MBSE teams). Parametric tools (e.g., SolidWorks, CATIA) excel in geometric exploration, while simulation tools (e.g., ANSYS, MATLAB) validate performance under defined constraints. Hybrid workflows (e.g., SysML + Simulink) are common in systems engineering.

      Parametric Modeling for Exploring "What" Scenarios

      Parametric modeling allows engineers to define relationships between design variables and automatically propagate changes, enabling rapid exploration of "what-if" scenarios. For example, adjusting a load parameter in a finite element model (FEM) or modifying a material property in a thermal simulation reveals how the system responds without rebuilding physical prototypes. Below are two critical applications:

      1. Design Space Exploration
      Parametric tools use design tables or sweeps to evaluate multiple configurations. For instance, in SolidWorks, a design table can link geometric dimensions (e.g., wall thickness) to performance metrics (e.g., deflection), generating a Pareto front of optimal trade-offs. This is particularly useful in:

    • Topology optimization: Identifying material distribution for minimum weight under load constraints.
    • Robustness analysis: Assessing sensitivity to manufacturing tolerances (e.g., ±0.5mm in a shaft diameter).

      • 2. Dynamic Simulation with Coupled Parameters
      Tools like Simulink or ANSYS enable co-simulation, where mechanical, thermal, and electrical parameters are linked. For example:

    • A battery thermal model in ANSYS Fluent can couple with an electrical circuit in Simulink to predict temperature rise during fast charging.
    • A control system in MATLAB can simulate a motor’s response to parametric changes in inertia or voltage, validating stability margins before prototyping.

      • Example Workflow for Parametric Exploration:

      Scenario: Evaluating a cantilever beam’s deflection under increasing load.
      Steps:
      1. Define the beam geometry in SolidWorks with parametric dimensions (e.g., length L, thickness t).
      2. Create a

      what in engineering - Ilustrasi 3

      Ethical and Societal Dimensions Defining the "What" in Engineering

      Engineering decisions are not made in isolation; they emerge from a complex interplay of societal needs, ethical imperatives, and regulatory constraints. The definition of the "what" in engineering—whether in product design, infrastructure development, or technological innovation—must account for broader impacts on equity, sustainability, and public welfare. Ethical considerations and societal priorities often act as boundary conditions, shaping project objectives before technical feasibility or economic viability. Regulatory frameworks further codify these dimensions, ensuring that engineering solutions align with collective well-being while mitigating risks. This section explores how ethical and societal factors explicitly and implicitly define the "what" in engineering, including their influence on stakeholder priorities, regulatory compliance, and decision-making trade-offs.

      Societal Needs and Ethical Considerations as Defining Constraints for Engineering "What"

      Societal needs and ethical principles serve as foundational constraints that precede technical problem-solving. Engineers must address questions such as: Whose needs are prioritized? and What long-term consequences arise from design choices? For example, accessibility in public infrastructure ensures inclusion for individuals with disabilities, while sustainability mandates reduce environmental harm. These considerations are not optional but are increasingly embedded in engineering standards, corporate policies, and public expectations.

      The following table illustrates how ethical and societal factors influence the definition of engineering "what," with real-world examples and engineering responses:

      Ethical/Societal Factor Example Impact on "What" Engineering Response Case Study
      Accessibility Design must accommodate diverse user abilities, including mobility, sensory, and cognitive needs. Integration of universal design principles (e.g., ramps, tactile pathways, adjustable interfaces) into product and infrastructure specifications. Example: The Americans with Disabilities Act (ADA) mandates accessible public buildings, leading to standardized door widths (32 inches minimum), automatic door openers, and compliant restroom designs. Engineers in transportation systems (e.g., subway cars) incorporate priority seating, audible announcements, and tactile floor indicators.
      Sustainability Projects must minimize resource depletion, pollution, and carbon footprints while ensuring long-term viability. Adoption of life-cycle assessment (LCA) tools, renewable energy integration, and circular economy principles (e.g., modularity, recyclable materials). Example: The European Union’s Ecodesign Directive requires appliances like refrigerators to meet energy efficiency standards (e.g., A+++ ratings), forcing engineers to optimize insulation, compressor efficiency, and material selection. Tesla’s Gigafactories prioritize solar-powered operations and battery recycling programs.
      Privacy and Data Security Technologies must protect user data from unauthorized access or misuse, especially in IoT and AI systems. Implementation of encryption protocols, anonymization techniques, and compliance with laws like GDPR or CCPA. Ethical AI frameworks ensure transparency and bias mitigation. Example: Apple’s iPhone design incorporates hardware-level privacy features (e.g., Secure Enclave for biometric data) and restricts app access to user location without explicit consent. Engineers at Google developed differential privacy in data analytics to prevent re-identification of individuals.
      Equity and Inclusivity Solutions must address disparities in access to technology, education, or healthcare, particularly in marginalized communities. Development of low-cost, adaptable technologies (e.g., open-source medical devices) and culturally sensitive design iterations. Example: The Open Source EHR (Electronic Health Record) projects, like OpenMRS, enable rural clinics in Africa to use affordable, locally customizable health IT systems. Engineers at D-Rev designed the Merry-Go-Round ventilator for low-resource settings, reducing costs by 90% while maintaining functionality.
      These examples demonstrate that the "what" in engineering is not solely a technical artifact but a negotiated outcome shaped by ethical trade-offs and societal values. Engineers must balance competing priorities, such as cost efficiency versus environmental impact or innovation speed versus safety, while ensuring designs remain responsive to diverse stakeholders.

      Regulatory Frameworks as Explicit Definitions of Engineering "What"

      Regulatory frameworks act as formalized constraints that explicitly define the permissible scope of engineering "what." Laws, standards, and industry codes establish minimum requirements for safety, environmental protection, and public health, often preempting or guiding design decisions. These frameworks can be categorized into three types:
      1. Safety and Health Regulations (e.g., OSHA, ISO 13485 for medical devices),
      2. Environmental Protection Laws (e.g., EPA’s Clean Air Act, REACH in the EU),
      3. Consumer and Industry Standards (e.g., IEEE safety standards for electrical systems, ASTM for construction materials).

      Regulatory compliance frequently dictates the "what" by:

    • Eliminating infeasible options (e.g., lead-based paints are banned in the U.S. under the Toxic Substances Control Act, removing them from building material specifications).
    • Imposing design requirements (e.g., the Energy Independence and Security Act (EISA) 2007 mandates minimum energy efficiency standards for lighting, forcing LED bulb designs to meet lumen-per-watt thresholds).
    • Enabling certification pathways (e.g., UL 94 flammability ratings for plastics, which engineers must reference when selecting materials for electronics enclosures).

      • The interplay between regulations and engineering "what" is dynamic. For instance, the EU’s Right to Repair initiative (2021) requires manufacturers to provide spare parts and documentation for electronic devices, directly influencing product design modularity and disassembly ease. Engineers must interpret and apply these regulations creatively, often collaborating with legal and policy experts to align designs with evolving standards.

      Stakeholder Conflicts in Defining Engineering "What": A Hypothetical Scenario and Decision-Making Framework

      Engineers often face scenarios where conflicting stakeholder priorities necessitate trade-offs in defining the "what." Consider the following hypothetical case:

      Scenario: Designing a Smart Grid for a Rural Community
      A multidisciplinary team is tasked with designing a smart grid for a rural community with:

    • Limited infrastructure (aging power lines, intermittent renewable energy sources),
    • Diverse stakeholders (local government prioritizing cost savings, environmental NGOs demanding renewable integration, residents concerned about blackout risks),
    • Technological constraints (high initial costs for battery storage vs. reliance on diesel generators).

      • The team must choose between two primary "what" definitions:
      1. Option A: A hybrid system combining solar microgrids with diesel backup, ensuring reliability but higher emissions and operational costs.
      2. Option B: A fully renewable system with advanced battery storage and demand-response software, reducing emissions but requiring higher upfront investment and potential reliability risks during peak demand.

      Decision-Making Process:
      To resolve this conflict, engineers employ a structured ethical and stakeholder analysis framework:

      1. Stakeholder Mapping and Prioritization

    • Identify and weight stakeholders by influence and legitimacy (e.g., government mandates carry more weight than individual complaints).
    • Example: The local government’s budget constraints may override resident preferences for aesthetics if funding is contingent on cost efficiency.

      • 2. Ethical Impact Assessment

    • Apply frameworks like the Engineering Code of Ethics (NSPE) or Utilitarianism to evaluate outcomes:
    • Option A prioritizes immediate reliability but perpetuates fossil fuel dependency, harming long-term sustainability.
    • Option B aligns with climate goals but risks short-term blackouts, disproportionately affecting vulnerable populations.
    • Use multi-criteria decision analysis (MCDA) to quantify trade-offs (e.g., cost vs. emissions vs. reliability).

      • 3. Regulatory and Policy Alignment

    • Check for local/national incentives (e.g., subsidies for renewable projects under the Inflation Reduction Act) or penalties (e.g., carbon taxes).
    • Example: If the region offers tax breaks for renewable projects, Option B becomes financially viable despite higher costs.

      • 4. Iterative Prototyping and Feedback

    • Develop pilot models for both options and solicit input from affected communities (e.g., surveys on willingness to tolerate blackouts for lower emissions).
    • Example: A phased rollout could test Option B in one village, using data to refine reliability before full deployment.

      • 5. Transparency and Just

      Historical Evolution of Engineering "What": From Empirical Foundations to Computational Systems

      Engineering’s definition of "what" has undergone profound transformations, reflecting shifts in human knowledge, technological capabilities, and societal needs. Early civilizations approached engineering as an empirical art, relying on trial-and-error and inherited craftsmanship. Over millennia, the evolution of mathematical rigor, industrialization, and digital computation redefined the "what"—from static structures to dynamic, adaptive systems. This progression reveals how engineering challenges not only shaped physical infrastructure but also expanded the boundaries of what is technically and ethically feasible. Below, the timeline traces these shifts, comparing foundational eras and examining how pivotal projects like the Panama Canal redefined engineering priorities.

      Timeline of Engineering "What": Key Eras and Paradigm Shifts

      The definition of "what" in engineering has evolved through distinct phases, each marked by advancements in materials, analysis, and systemic integration. The transitions between these eras reflect broader intellectual movements—from intuitive construction to predictive modeling—and underscore how engineering adapts to address new challenges.

      Empirical Era (Pre-3000 BCE – 17th Century)
      The earliest engineering focused on survival and monumentality, with "what" determined by local resources, cultural symbolism, and manual labor. Structures like the Great Pyramid of Giza (c. 2580–2560 BCE) exemplify this phase, where empirical knowledge of geometry, gravity, and material properties (e.g., limestone blocks, ramps) was passed down without formalized theory. The "what" here was functional permanence: buildings, irrigation systems, and tools designed to last generations without analytical validation.

      "Engineering in antiquity was a synthesis of craft, observation, and myth—where the 'what' was as much about divine approval as structural integrity." — Adapted from Herodotus’ Histories and Vitruvius’ De Architectura.
      Analytical Era (17th–19th Century)
      The Scientific Revolution introduced quantitative methods, shifting "what" toward measurable performance. Key milestones include:
    • Galileo’s (1564–1642) work on mechanics, which formalized principles of stress and motion, enabling the design of bridges and clocks with calculable limits.
    • Leonardo da Vinci’s (1452–1519) sketches, blending art and engineering to explore fluid dynamics and structural optimization.
    • The Industrial Revolution (late 18th–19th century), where James Watt’s steam engine (1776) and George Stephenson’s railways (1825) redefined "what" as scalable efficiency. Factories and transportation systems prioritized standardization, energy conversion, and mass production, replacing empirical rules with engineering drawings and material science.
      • "The Industrial Revolution transformed the 'what' from 'build what can be built' to 'build what can be replicated at scale.'" — Henry Petroski, The Evolution of Useful Machines.
      Systemic Era (20th Century – Present)
      The 20th century introduced interconnected systems, where "what" expanded to encompass networks, feedback loops, and human-machine collaboration. Critical developments include:
    • Electrification (late 19th–early 20th century): Nikola Tesla’s AC power grids (1880s) and Thomas Edison’s distribution networks redefined "what" as energy infrastructure, requiring coordination across cities.
    • Space Race (1957–1969): Wernher von Braun’s Saturn V rocket (1967) exemplified systemic integration, where "what" involved aerodynamics, propulsion, and life-support subsystems operating in unison.
    • Digital Revolution (1970s–Present): The rise of computational modeling (e.g., finite element analysis in the 1960s) and AI-driven optimization (2010s) shifted "what" toward adaptive, data-informed design. Modern examples include:
    • Smart grids (e.g., California’s ISO grid management) balancing supply/demand in real-time.
    • Autonomous infrastructure (e.g., self-healing roads with embedded sensors) that dynamically respond to environmental stressors.
      • "Today’s engineering 'what' is no longer static; it is a living system—one that learns, predicts, and evolves through continuous feedback." — Don Norman, The Design of Everyday Things (2013).

      Comparative Analysis: Industrial Revolution vs. Digital Age

      The shift from the Industrial Revolution to the Digital Age illustrates how technological advancements redefined the core questions of engineering "what", alongside philosophical underpinnings.
      AspectIndustrial Revolution (18th–19th Century)Digital Age (21st Century)
      Primary FocusMechanization and mass productionInformation processing and adaptive systems
      Key TechnologiesSteam engines, iron/steel production, railways, telegraphyMicroprocessors, IoT, AI/ML, quantum computing, nanotechnology
      Definition of "What""What can be built to replace manual labor?" (e.g., factories, bridges)"What can be simulated, optimized, or autonomously managed?" (e.g., AI-driven traffic systems)
      Design ProcessRule-based, standardized (e.g., blueprints, material tables)Model-based, iterative (e.g., digital twins, generative design)
      Ethical PrioritiesWorker safety, resource extraction, urbanizationData privacy, algorithmic bias, sustainability, human-AI collaboration
      ExamplesPanama Canal (1914): Defined "what" as hydrological and logistical mastery over nature.Tesla’s Autopilot (2014–Present): Redefines "what" as autonomous decision-making in dynamic environments.
      Technological Shifts:
    • From Physical to Virtual: The Industrial Revolution’s "what" was tangible (e.g., a bridge’s load-bearing capacity), while the Digital Age’s "what" often exists in simulated or abstract spaces (e.g., a neural network’s decision-making logic).
    • From Centralized to Distributed: Factories centralized production; today, edge computing and decentralized AI distribute intelligence across systems.
    • From Predictive to Prescriptive: 19th-century engineers predicted failure (e.g., via stress analysis); 21st-century engineers prescribe actions (e.g., AI adjusting wind turbine blades in real-time).

      • Philosophical Shifts:

    • Determinism vs. Adaptability: Industrial-era engineering assumed static conditions (e.g., a bridge’s design for a fixed load). Modern engineering embraces uncertainty (e.g., designing for climate variability or cyber threats).
    • Human-Centric to Human-Machine Symbiosis: The "what" now often involves co-design with AI, where systems like Boston Dynamics’ robots or autonomous drones augment human capabilities rather than replace them.

      • Case Study: The Panama Canal (1904–1914) and Its Redefinition of Engineering "What"

      The construction of the Panama Canal stands as a pivotal redefinition of engineering "what" by integrating hydrology, geopolitics, and large-scale logistics into a single, unprecedented challenge. Before its completion, the "what" of canal engineering was constrained by:
    • Empirical limitations: Previous attempts (e.g., the failed Nicarágua Canal proposal, 1890s) relied on trial-and-error excavation, leading to catastrophic failures (e.g., landslides, disease outbreaks).
    • Technological silos: Civil, mechanical, and medical engineering operated independently, with no overarching framework for systemic risk assessment.

      • How the Panama Canal Redefined "What":
      1. Interdisciplinary Integration
      The project required simultaneous advancements in:

    • Hydraulic engineering: Lock systems to manage water levels (designed by John F. Stevens and refined by George W. Goethals).
    • Disease control: William Gorgas’ mosquito eradication (1906) addressed the "what" of human survival as a prerequisite to construction.
    • Material innovation: Concrete for locks (instead of wood) and steel cranes for dredging, both of which were tested under extreme conditions.

      • 2. Logistical Systems Engineering
      The "what" expanded to include supply-chain optimization:

    • Railway networks to transport excavated material (20 million cubic yards of dirt moved via Culebra Cut).
    • Standardized labor coordination: A workforce of 75

      The essence of what in engineering lies in its ability to bridge ambition with feasibility, ensuring that every project—from ancient marvels to cutting-edge technologies—begins with a clear, rigorous definition of its objectives. By mastering this foundational step, engineers not only mitigate risks but also unlock innovative solutions that align with human needs, ethical standards, and technological capabilities. The historical evolution of engineering what—from empirical trial-and-error to data-driven precision—underscores its dynamic nature, where each advancement redefines the boundaries of possibility. Ultimately, the what remains the cornerstone of engineering excellence, demanding precision, foresight, and adaptability in an increasingly complex world.

      • FAQ

      What does civil engineering involve as a field?

      Civil engineering focuses on designing, constructing, and maintaining infrastructure like roads, bridges, buildings, water systems, and airports. It combines principles of physics, math, and materials science to ensure safety, sustainability, and functionality in public works. Professionals in this field often work on urban planning, environmental projects, or structural analysis.

      What does mechanical engineering entail as a career?

      Mechanical engineering involves designing, analyzing, and manufacturing mechanical systems, including engines, HVAC systems, robots, and machinery. It blends core areas like thermodynamics, kinematics, and materials science to solve problems in energy, transportation, and automation. Engineers in this field often work in manufacturing, aerospace, or automotive industries.

      What course should I take to start a career in engineering?

      To begin an engineering career, take foundational courses in math (calculus, linear algebra), physics, chemistry, and computer programming. Early undergraduate courses often include introductory engineering, statics, dynamics, and circuit theory, depending on your specialization. Prerequisites vary by program, but STEM subjects are universally required.

      What skills and tasks are involved in software engineering?

      Software engineering combines programming, problem-solving, and system design to develop, test, and maintain software applications or systems. Key tasks include writing code (in languages like Python or Java), debugging, collaborating with teams, and optimizing performance. It also involves software architecture, cybersecurity, and project management.

      What does electrical engineering focus on as a discipline?

      Electrical engineering deals with the study and application of electricity, electronics, and electromagnetism to design systems like power grids, semiconductors, communication networks, and control systems. It covers areas such as circuit design, signal processing, and renewable energy technologies. Engineers in this field often work in tech, telecommunications, or energy sectors.

      What types of jobs are available in engineering fields?

      Engineering jobs span diverse industries, including aerospace, automotive, civil, mechanical, electrical, and software roles. Common positions are design engineer, project manager, research scientist, systems analyst, or consultant. Many engineers also work in R&D, quality assurance, or technical sales, with opportunities in both corporate and government sectors.