6. Edge, Fog, IoT, and Cyber-Physical ArchitecturesIntroduction and ContextCloud computing centralized computation, storage, and analytics in elastic data centers. That model remains powerful, but it is insufficient for every workload. Industrial robots, autonomous vehicles, augmented-reality systems, remote healthcare devices, and safety-critical infrastructure often require decisions within milliseconds, continuous operation during network disruption, and local handling of sensitive data. Sending every sensor observation to a distant cloud introduces communication delay, bandwidth consumption, privacy exposure, and dependence on wide-area connectivity. Edge computing addresses this problem by placing computation, storage, control, and analytics close to the sources and consumers of data. The edge may be a sensor gateway, a factory server, a telecommunications base station, an on-board vehicle computer, or a small device attached to machinery. Fog computing extends this idea into a distributed hierarchy between end devices and centralized cloud platforms. The Internet of Things (IoT) supplies the sensing and actuation fabric, while cyber-physical systems (CPS) integrate computational processes with physical processes through feedback loops. These architectures are not merely smaller versions of cloud infrastructure. They operate under heterogeneous hardware, intermittent connectivity, limited energy, mobility, uncertain data quality, and physical consequences of software decisions. Architectural design must therefore address not only throughput and scalability but also timing, safety, autonomy, resilience, explainability, and governance. Learning ObjectivesAfter studying this chapter, the reader should be able to: 1. Distinguish edge computing, fog computing, IoT, mobile edge computing, and cyber-physical systems. 2. Design layered architectures for constrained, heterogeneous, and intermittently connected environments. 3. Evaluate latency, bandwidth, mobility, autonomy, reliability, safety, and real-time requirements. 4. Explain the role of gateways, sensor networks, digital twins, orchestration, and event-driven control. 5. Select suitable cloud–edge placement strategies for industrial, transportation, healthcare, and smart-environment applications. 6. Critically assess security, privacy, ethical, regulatory, and operational risks. 7. Identify research challenges and emerging directions in edge and cyber-physical architectures. From Cloud-Centric Computing to Distributed Physical IntelligenceA useful distinction is between where data is generated, where it is interpreted, and where action is taken. In a conventional cloud-centric design, data generated by devices travels to a remote service, is processed centrally, and produces a command that returns to the device. This arrangement simplifies administration and supports global analytics, but the round trip may be too slow or too unreliable for time-sensitive control. An edge architecture moves some functions nearer to the device. A gateway may filter measurements, translate protocols, authenticate devices, and execute local rules. A more capable edge server may run machine-learning inference, digital-twin synchronization, video analysis, or local optimization. The cloud generally remains valuable for fleet-wide learning, historical analysis, model training, long-term storage, and cross-site coordination. Fog computing is commonly described as an intermediate, distributed layer that coordinates resources across devices, local networks, access networks, and cloud systems. The distinction between edge and fog is not universally fixed. Edge usually emphasizes proximity to the data source or endpoint; fog emphasizes a hierarchical or federated continuum of distributed resources. In practice, the terms overlap, and architecture should be described by actual placement and responsibility rather than by terminology alone. IoT is primarily an ecosystem of identifiable physical objects, sensors, actuators, communication networks, software, and services. It does not imply that all processing occurs at the edge. A simple IoT device can report data to the cloud, whereas an intelligent IoT system may perform local perception and autonomous control. A CPS is characterized by a tight interaction between computational logic and physical dynamics. A thermostat, automated warehouse, aircraft control system, and smart grid are examples of CPS. The defining issue is not simply connectivity but feedback: sensors observe a physical process, computation estimates or decides, and actuators alter that process. Timing and correctness therefore have physical significance. Architectural Continuum and Core ConceptsA practical architecture can be viewed as a continuum rather than a binary cloud-versus-device choice: Device and sensor layer. Sensors measure temperature, vibration, position, pressure, image data, electrical current, or biological signals. Actuators produce physical effects. Devices may be battery-powered, computationally weak, intermittently connected, or exposed to hostile environments. Access and network layer. Wired industrial networks, Wi-Fi, cellular networks, low-power wide-area networks, mesh networks, and emerging private 5G systems connect devices. This layer must tolerate variable bandwidth, packet loss, mobility, and changing topology. Gateway layer. Gateways aggregate devices, translate protocols, buffer data, enforce policy, provide local identity management, and sometimes execute control logic. They are especially important where legacy equipment uses protocols that cannot directly communicate with cloud services. Local edge layer. Edge nodes provide low-latency computation, stream processing, inference, caching, and local coordination. They may be deployed on premises, in a vehicle, at a base station, or in a micro-data center. Regional fog layer. Fog resources coordinate multiple edge sites, provide additional capacity, and support applications whose scope exceeds one local environment but does not require global cloud placement. Cloud and enterprise layer. Cloud platforms support large-scale storage, model training, enterprise integration, global optimization, digital-twin history, and software lifecycle management. This layering is conceptual, not a requirement for physically separate products. A gateway and edge server may be one device, and a cloud service may expose edge deployment capabilities. The important design question is which function is placed where and what happens when a layer becomes unavailable. Latency, deadlines, and localityLatency is not only network round-trip time. It includes sensing, queueing, protocol processing, computation, serialization, scheduling, and actuation. For a control loop, a useful approximation is: T_loop = T_sense + T_uplink + T_compute + T_downlink + T_actuate The loop must satisfy the application deadline, with sufficient margin for variation. Average latency can be misleading: a system with a low mean but frequent deadline violations may be unsuitable for control. Tail latency, jitter, worst-case execution time, and deadline-miss probability are often more informative. Intermittency and autonomyEdge environments cannot assume continuous cloud access. A resilient design defines an autonomy envelope: the set of functions that remain available during disconnection. Local safety interlocks and essential control should normally remain operational; nonessential analytics, synchronization, and fleet reporting may be deferred. Store-and-forward queues, local snapshots, conflict resolution, and explicit degradation modes are central techniques. MobilityIn mobile edge computing, devices, users, and sometimes the edge service itself move. A vehicle may cross cellular cells, an industrial asset may move between zones, and a user may transition between access points. Mobility creates changing latency, identity, location, and resource conditions. Service migration, state replication, predictive placement, and session continuity can reduce disruption, but migration itself consumes bandwidth and may introduce security risks. Heterogeneity and semantic interoperabilityEdge systems combine processors, operating systems, protocols, data models, and trust domains. Interoperability requires more than a common transport protocol. Devices must agree on the meaning, units, time reference, quality, and provenance of data. Gateways can perform protocol translation, but excessive translation may obscure semantics and create maintenance burdens. Metadata, ontologies, schemas, versioning, and precise interface contracts are therefore architectural assets. Gateways, Sensor Networks, and Data Life CyclesThe gateway is often the most strategically important component in a constrained environment. It protects low-power devices from direct exposure, aggregates redundant data, converts protocols, and acts as a policy enforcement point. It can also perform feature extraction—for example, transmitting vibration anomalies rather than every raw waveform. Such reduction saves bandwidth, but it may remove evidence needed for later investigation. A sound design defines retention and sampling policies according to operational and forensic requirements. Sensor networks introduce uncertainty. Measurements contain noise, drift, missing values, calibration error, and synchronization differences. Edge analytics should therefore distinguish raw observations from derived events and should record confidence, timestamp quality, sensor identity, and calibration state. A decision based on a single unvalidated sensor should not automatically trigger a dangerous physical action. Sensor fusion, plausibility checks, redundancy, and safe-state logic are important safeguards. Time synchronization deserves special attention in distributed CPS. Comparing measurements from unsynchronized devices can produce false conclusions about causality. Depending on the application, systems may use network time services, hardware-assisted synchronization, sequence numbers, or bounded-clock-error models. The appropriate precision depends on the physical process and control deadline. A typical data life cycle is: acquisition, validation, normalization, local filtering, feature extraction, event detection, temporary buffering, action, synchronization, long-term storage, and model improvement. Each stage should have explicit ownership and failure behavior. For example, an edge node may retain raw data for a short period, publish an anomaly event immediately, and upload selected evidence when connectivity returns. Architectural Models for Edge and Fog SystemsHierarchical deploymentIn a hierarchical model, devices report to gateways, gateways report to local servers, and local servers synchronize with regional or cloud services. This is relatively easy to reason about and supports policy inheritance. Its weakness is that failure or overload at an upper layer can affect many lower-level devices unless local autonomy is designed deliberately. Federated and peer-to-peer deploymentIn a federated model, multiple edge sites cooperate while retaining administrative independence. A hospital, transport operator, and cloud provider may exchange selected services or models without sharing all raw data. Peer-to-peer cooperation can improve resilience and locality, but it complicates trust, discovery, consistency, and accountability. Event-driven deploymentEvent-driven architectures transmit meaningful state changes rather than constant polling. Rules at the edge can detect threshold crossings, patterns, or anomalies and publish events to subscribers. This reduces traffic and supports responsive control. Designers must nevertheless manage event ordering, duplication, idempotency, backpressure, and replay. Function and container placementEdge applications may be packaged as containers, lightweight virtual machines, or specialized binaries. Placement decisions should consider CPU, memory, accelerators, energy, data locality, deadline, privacy, and failure domains. A model may be split so that preprocessing occurs on a device, inference on an edge server, and retraining in the cloud. Placement must also account for operational cost: distributing many versions to thousands of sites increases update and observability complexity. Digital twinsA digital twin is a continuously maintained computational representation of a physical asset, process, or environment. It is more than a static CAD model or database record. A useful twin links identity, state, telemetry, history, models, constraints, and permitted actions. Edge resources maintain near-real-time state and support local diagnosis; cloud resources may perform long-term simulation, fleet comparison, and model training. Twin fidelity should match purpose. A predictive-maintenance twin may need vibration features and operating context, while a process-control twin may require a validated dynamic model with bounded timing. A twin can become dangerous if stale state is presented as current or if a prediction is treated as a fact. Freshness indicators, uncertainty estimates, provenance, and authorization boundaries are therefore necessary. Designing for Real-Time Behavior and SafetyNot every edge application is hard real-time. A hard real-time task must meet its deadline, whereas a soft real-time task experiences degraded quality when late. A safety-critical task is one in which failure can cause unacceptable harm. These categories overlap but are not identical: a video recommendation may be soft real-time but not safety-critical; an emergency shutdown may be safety-critical and hard real-time. Architecture should separate safety functions from convenience functions. A cloud-based dashboard may inform an operator, but it should not be the sole mechanism for preventing an industrial machine from exceeding a safe limit. Independent interlocks, watchdogs, redundant sensing, fail-safe actuators, and formally specified constraints may be required. A control architecture often combines three loops. The innermost loop executes rapidly and locally, such as motor stabilization. A middle loop performs supervisory control and local optimization. An outer loop conducts fleet analytics, planning, and model training. Moving a function outward may improve computational capacity but increases dependence on communication. Moving it inward improves responsiveness but consumes scarce edge resources and may complicate updates. Verification must include timing and environmental assumptions. Testing only normal network conditions is inadequate. Engineers should inject packet loss, clock drift, stale data, sensor disagreement, resource exhaustion, corrupted models, and delayed commands. Digital simulation and hardware-in-the-loop testing can expose failures before deployment, but simulation models themselves require validation. Security, Privacy, Governance, and EthicsThe edge expands the attack surface. Devices may be physically accessible, poorly patched, shared among organizations, or deployed with inconsistent configurations. Threats include device impersonation, firmware tampering, credential theft, lateral movement from a gateway, data poisoning, denial of service, model extraction, and unauthorized actuation. A defensible architecture applies layered controls: hardware-rooted identity where available, secure boot, signed firmware, encrypted communication, certificate or key rotation, least privilege, network segmentation, remote attestation, tamper evidence, vulnerability management, and centralized—but not exclusively cloud-dependent—monitoring. Local policy caches are useful when the cloud is unreachable. Updates should support rollback and staged deployment because an incorrect update can disable an entire operational site. Privacy is especially significant when edge devices process location, video, health, biometric, or workplace data. Edge processing can reduce transmission of raw data, but it does not automatically guarantee privacy. Local systems still need purpose limitation, data minimization, retention controls, access logging, consent or lawful authority, and protection against inference. Differential privacy, federated learning, and secure aggregation may help in appropriate settings, although they introduce accuracy, computational, or governance trade-offs. CPS governance must assign responsibility for automated decisions. Operators need to know whether a command was generated by a rule, a learned model, or a remote human. Audit trails should record model version, input quality, policy context, timestamp, decision, and override. In safety-relevant environments, explainability should be operationally meaningful: the system should indicate the evidence and constraint that led to an action, not merely provide an abstract confidence score. Regulatory obligations vary by sector and jurisdiction. Medical, automotive, aviation, energy, and industrial systems may be subject to safety, cybersecurity, privacy, quality, and records requirements. Architecture should map controls to applicable obligations rather than treating compliance as a final documentation exercise. Practical Industry ApplicationsIn smart manufacturing, edge nodes ingest machine telemetry, detect abnormal vibration, and coordinate production cells. Local inference can stop or slow equipment without waiting for cloud analysis, while the cloud compares patterns across plants. The major concerns are deterministic timing, legacy protocol integration, safety segregation, and minimizing disruption during updates. In transportation, vehicles process camera, lidar, radar, and positioning data locally because raw streams are too large and immediate decisions are necessary. Roadside edge infrastructure can provide cooperative perception or traffic optimization. Mobility, intermittent connectivity, adversarial inputs, and responsibility for automated decisions create substantial challenges. In healthcare, bedside and wearable devices can detect deterioration and prioritize alerts. Edge processing may protect sensitive data and reduce alert latency. However, false positives, false negatives, device calibration, clinical validation, cybersecurity, and human oversight must be addressed. An edge model should support clinical decision-making only within its validated scope. In energy systems, distributed sensors and controllers monitor substations, renewable generation, storage, and demand. Local control supports grid stability during communication loss, while regional and cloud services optimize resources. The architecture must accommodate long equipment lifetimes, strict access control, and cascading-failure risks. In agriculture and environmental monitoring, low-power devices may communicate intermittently over long distances. Gateways aggregate data and execute irrigation or hazard-detection rules. Energy harvesting, calibration, weather exposure, and sparse maintenance favor simple local policies and efficient communication. Illustrative Case Study: Edge-Controlled Predictive Maintenance in a Distributed FactoryBackgroundConsider Meridian Components, a fictional manufacturer operating several plants. Each plant contains legacy milling machines from different vendors. A cloud dashboard already collects selected temperature and production data, but maintenance teams report that failures are often detected too late. The company proposes an edge architecture for vibration analysis and local protective action. Situation and problemRaw vibration streams are high volume and cannot reliably be sent to the cloud over the existing network. Machine failures can damage tooling and cause extended downtime. At the same time, a false shutdown interrupts production and may create safety concerns if operators bypass the system. Connectivity between plants and the central platform is occasionally unavailable. AnalysisThe failure-detection task has two distinct requirements. Feature extraction and anomaly detection must occur close to each machine because of bandwidth and response constraints. Fleet-wide model training can occur in the cloud because it is not part of the immediate control loop. A safety shutdown must not depend solely on a statistical model; it requires an independent threshold and interlock mechanism validated by engineering staff. The plants also differ in equipment age and sensor quality. A single global model could perform poorly when transferred across machines. The design therefore needs machine-specific calibration, confidence reporting, and a model governance process. Architecture and strategySensors connect to industrial gateways through appropriate local protocols. Each gateway validates timestamps, checks sensor health, extracts frequency-domain features, and retains a short rolling buffer of raw data. A plant edge server aggregates features from several machines, runs anomaly models, and publishes alerts to the maintenance system. A separate safety controller handles hard protective limits. When a model detects an anomaly, the edge server records the model version, evidence, confidence, and machine state. It can request a controlled inspection or reduce operating speed, but it cannot override the independent safety controller. Selected evidence is uploaded to the cloud when connectivity is available. The cloud compares machines across plants, trains candidate models, and distributes signed updates through staged rollout. Gateways continue operating with the previous approved model if the update fails validation. The system includes a local autonomy policy. During cloud disconnection, essential detection and approved local responses continue; fleet dashboards become stale, and model retraining is suspended. When the connection returns, buffered events are reconciled using unique identifiers and event timestamps. OutcomeThe architecture reduces dependence on wide-area communication and separates predictive assistance from safety protection. Maintenance staff receive earlier, evidence-based alerts, while operators retain authority to investigate and override non-safety recommendations according to procedure. The most important result is not simply lower latency but clearer responsibility: the edge performs time-sensitive analysis, the safety controller enforces physical limits, and the cloud manages historical learning and fleet coordination. Learning pointsThe case demonstrates five principles. First, placement should follow deadlines and failure consequences. Second, a digital or statistical model must not be confused with a certified safety mechanism. Third, local autonomy requires explicit degraded modes. Fourth, model and data provenance are necessary for accountable operations. Fifth, heterogeneous assets require adaptation rather than blind reuse of a single model. Challenges, Limitations, and Common Design ErrorsEdge systems are operationally difficult because they combine distributed computing with physical deployment. Resource capacity is uneven, observability is incomplete, and maintenance may require physical access. A design that works in a laboratory may fail when thousands of devices have different firmware, clock quality, or environmental conditions. Common errors include placing every function at the edge without considering lifecycle cost; sending all raw data to the cloud despite bandwidth and privacy constraints; relying on average rather than worst-case latency; assuming network availability; treating a gateway as a single trusted boundary; deploying machine-learning models without drift monitoring; and allowing remote commands without a safe local override. Consistency is another fundamental limitation. Strong global consistency may be impossible or too expensive during intermittent connectivity. Designers must identify which state requires strict ordering and which state can be eventually consistent. Conflict policies should be explicit rather than left to accidental message order. Observability also becomes harder. Central logs may be unavailable during faults, while local logs may be incomplete or tampered with. Secure time-stamped event records, health summaries, remote diagnostics, and controlled forensic retention are necessary. Finally, edge deployments can increase energy consumption, electronic waste, and inequality if infrastructure is concentrated in well-connected regions. Sustainability should include device lifetime, repairability, energy use, and responsible decommissioning. Emerging Directions and Research QuestionsSeveral developments are shaping research and practice. Cloud–edge continuum platforms increasingly automate placement and scaling across devices, access networks, and data centers. Artificial intelligence is moving toward collaborative and federated learning, where models are improved across sites without centralizing all raw data. Tiny machine-learning models and specialized accelerators enable inference on constrained devices, although model compression can affect accuracy and robustness. Private cellular networks, programmable networks, and multi-access edge computing provide new locations for low-latency services. Digital twins are becoming more connected to simulation, optimization, and operational control. Research is also examining semantic interoperability, trustworthy autonomy, adversarial robustness, confidential computing, and verifiable AI for physical systems. Important open questions remain. How can placement algorithms provide predictable deadlines under uncertain workloads? How should edge AI uncertainty be represented in control decisions? How can federated systems detect poisoned updates without exposing sensitive data? What evidence is sufficient to certify adaptive software in safety-critical environments? How can organizations govern shared edge infrastructure across different owners and jurisdictions? These questions require computer science, control engineering, human factors, security, law, and organizational research to work together. Best Practices for Architecture and EvaluationA disciplined design process begins by describing physical processes, deadlines, failure consequences, data sensitivity, mobility patterns, and operating environments. Functions are then classified as safety-critical, real-time, privacy-sensitive, resource-intensive, or tolerant of delay. Candidate placements are evaluated against measurable requirements rather than fashion or product labels. Useful evaluation measures include end-to-end latency and jitter, deadline-miss rate, availability during disconnection, energy per inference or message, bandwidth reduction, detection precision and recall, recovery time, model drift, update success rate, and unauthorized-command probability. Experiments should include representative workloads, adverse network conditions, device failures, clock errors, and security attacks. Architects should preserve local safe operation, minimize unnecessary data movement, use explicit contracts and schemas, secure the complete lifecycle, separate advisory analytics from protective control, and design for rollback. They should also document assumptions: maximum outage duration, acceptable data staleness, clock accuracy, sensor confidence, recovery authority, and human override procedures. These assumptions are often more important than the nominal architecture diagram. Chapter SummaryEdge, fog, IoT, and cyber-physical architectures distribute computation across devices, gateways, local servers, regional resources, and clouds. Their purpose is not simply to reduce latency but to support locality, autonomy, resilience, privacy, and physically meaningful feedback. IoT supplies connected sensing and actuation; edge computing places functions near data sources; fog computing coordinates distributed intermediate resources; and CPS integrates computation with physical dynamics. Effective design begins with requirements for deadlines, mobility, intermittency, safety, energy, data quality, and governance. Gateways perform aggregation, translation, validation, security, and local processing. Digital twins connect physical assets with state, history, models, and permitted actions. Event-driven processing, model placement, buffering, synchronization, and explicit degraded modes are central architectural techniques. No cloud–edge placement is universally best. Safety functions require independent protection, while cloud services remain valuable for global learning and coordination. Security, privacy, provenance, update management, and human accountability must span the complete lifecycle. Evaluation should measure tail latency, deadline behavior, autonomy during outage, energy, accuracy, resilience, and operational maintainability. The field continues to develop through cloud–edge continuum orchestration, federated learning, specialized AI, digital twins, and verifiable autonomous systems. Key TermsEdge computing: Placement of computation, storage, and services near data sources or users. Fog computing: A distributed intermediate layer coordinating resources between endpoints and cloud systems. Internet of Things (IoT): An ecosystem of connected physical objects, sensors, actuators, networks, and services. Cyber-physical system (CPS): A system integrating computational processes with physical processes through sensing and actuation. Mobile edge computing: Edge computing in environments where users, devices, or services are mobile. Gateway: A device or service that aggregates, translates, secures, and processes traffic between local devices and wider networks. Digital twin: A continuously updated computational representation of a physical asset, process, or environment. Autonomy envelope: The set of functions that remain available during loss of external connectivity. Tail latency: High-percentile response time, often more relevant than average latency for real-time systems. Jitter: Variation in timing or delay across repeated operations. Intermittency: Irregular or temporary loss of network, power, or computational availability. Sensor fusion: Combining measurements from multiple sensors to improve estimation or reliability. Event-driven architecture: An architecture in which state changes or meaningful events trigger processing and communication. Model drift: Change in data or system conditions that reduces the performance of a deployed analytical model. Federated learning: Collaborative model training in which sites retain raw data locally and share selected model information. Safety interlock: An independent mechanism that prevents or limits hazardous physical operation. Store-and-forward: Buffering data locally until a communication path becomes available. Provenance: Traceable information about the origin, transformation, timing, and authority of data or decisions. Cloud–edge continuum: The range of computing resources from constrained devices through edge and fog nodes to centralized clouds. Review QuestionsShort Answer Questions1. How does edge computing differ from fog computing? 2. Why is average latency insufficient for evaluating a real-time CPS? 3. Identify three important functions performed by an IoT gateway. 4. What is meant by an autonomy envelope? 5. Why should a digital twin include freshness and uncertainty information? Long Answer Questions1. Explain a layered cloud–edge architecture and discuss the responsibilities of each layer. 2. Analyze the relationship between sensor quality, data provenance, and safe actuation in a CPS. 3. Discuss how mobility and intermittent connectivity influence mobile edge computing design. 4. Explain how digital twins support predictive maintenance while introducing governance risks. 5. Evaluate security and privacy controls for a heterogeneous edge environment. Analytical / Application Questions1. Design a placement strategy for an autonomous vehicle system that must continue operating during a two-minute network outage. Justify which functions belong in the vehicle, at roadside edge nodes, and in the cloud. 2. A hospital wants to use an edge model to detect patient deterioration from wearable data. Identify latency, privacy, safety, human oversight, and model-governance requirements. 3. An industrial plant experiences false alarms after deploying a common anomaly-detection model across old and new machines. Diagnose the architectural and data-related causes and propose a revised approach. 22. Multiple Choice Questions with AnswersQuestion 1Which architectural decision most directly supports operation during a prolonged cloud disconnection? A. Moving all analytics to a centralized cloud B. Defining a local autonomy envelope with buffering and degraded modes C. Increasing dashboard refresh frequency D. Removing local device authentication Correct Answer: B. Defining a local autonomy envelope with buffering and degraded modes Question 2Why is tail latency especially important in a cyber-physical control loop? A. It measures long-term storage capacity B. It reveals occasional delays that may cause deadline violations C. It eliminates the need for sensor calibration D. It guarantees model accuracy Correct Answer: B. It reveals occasional delays that may cause deadline violations Question 3Which function is most appropriately assigned to an IoT gateway? A. Global fleet-wide model training only B. Protocol translation, aggregation, and local policy enforcement C. Replacing every physical sensor with a cloud database D. Guaranteeing uninterrupted wide-area connectivity Correct Answer: B. Protocol translation, aggregation, and local policy enforcement Question 4In the illustrative factory case, why was the statistical anomaly model separated from the safety controller? A. Statistical models cannot process vibration data B. Safety protection should not depend solely on an uncertified predictive model C. Cloud systems cannot store machine data D. The safety controller required global historical data Correct Answer: B. Safety protection should not depend solely on an uncertified predictive model Question 5What is a principal risk of treating stale digital-twin state as current physical state? A. Reduced file compression B. An action may be based on an inaccurate representation of the asset C. Improved interoperability D. Lower sensor energy consumption Correct Answer: B. An action may be based on an inaccurate representation of the asset Question 6Which requirement is most associated with a hard real-time task? A. The task should meet a specified deadline predictably B. The task must always use cloud storage C. The task must use a machine-learning model D. The task must transmit all raw data Correct Answer: A. The task should meet a specified deadline predictably Question 7A mobile edge service moves between cellular coverage areas. Which technique can help preserve service continuity? A. Service migration or state replication B. Disabling device identity changes C. Eliminating local caching D. Using only batch processing Correct Answer: A. Service migration or state replication Question 8Why can transmitting only extracted features instead of raw sensor streams be problematic? A. Features always require more bandwidth B. Relevant evidence may be lost for later diagnosis or forensic analysis C. Features cannot be timestamped D. Raw data is never useful after an event Correct Answer: B. Relevant evidence may be lost for later diagnosis or forensic analysis Question 9Which control best limits the impact of a compromised edge device? A. Network segmentation and least privilege B. A shared administrator password C. Unverified firmware updates D. Disabling audit logs Correct Answer: A. Network segmentation and least privilege Question 10What is the primary purpose of federated learning in an edge environment? A. To require all raw data to be centralized B. To train collaboratively while retaining raw data at participating sites C. To remove the need for model monitoring D. To guarantee identical performance at every site Correct Answer: B. To train collaboratively while retaining raw data at participating sites
|
