5.6 Case Study and Deployment Checks

Author: Zhang Hongyuan · © 2016–2026 · All Rights Reserved · Copyright & License

5.6.1 An End-to-End Engineering Case: A Factory Equipment Condition Monitoring and Anomaly Alarm System

(This case is distilled from common industrial monitoring requirements and does not refer to any specific company or project.)

The preceding sections have taken the IoT platform apart layer by layer, from data acquisition to AI inference. Each stage looks sound on its own, yet once chained together, things can go wrong at every joint. This subsection uses one complete example — factory motor condition monitoring — to string the chapter's capstone pieces into a single end-to-end chain: sensor acquisition, edge protocol conversion, message-queue buffering, persistence into a time-series database, AI anomaly detection, and finally alarm delivery and visualization. You will see the full life cycle of an alarm event, from a sensor's vibration reading to an SMS on an engineer's phone.

Scenario Requirements

A machine shop needs condition monitoring for 30 motors. Each motor carries one three-axis vibration sensor and one temperature sensor, sampled in one reading set every 10 seconds. The plant's network is limited, so the raw data cannot all be uploaded directly to the cloud. The edge gateway therefore handles local caching and first-level alarm evaluation, while the cloud is responsible for long-term storage, cross-device trend analysis, and AI anomaly detection; once an anomaly is detected, it is pushed to the on-call engineer by SMS and email. What makes this scenario typical is that it covers the complete processing path along which data gets sparser, value gets higher, and latency gets lower.

System Architecture

The system consists of four tiers: device layer, edge layer, messaging layer, and cloud layer. Each tier carries one clear responsibility, and tiers are decoupled from one another through standard protocols.

Device layer: sensors send their data to the edge gateway over Modbus RTU. Each motor carries one (three-axis) MEMS accelerometer and one PT100 platinum-resistance temperature sensor whose 4–20 mA analog output is converted by a transmitter into a digital Modbus signal. Motors are numbered 01 through 30, each with a unique Modbus slave address. Modbus RTU is the lowest-cost industrial fieldbus option: the frame format is simple, and retrofitting existing equipment stays affordable.

Edge layer: the edge gateway is an x86 industrial PC. This example uses Node-RED and Mosquitto for reading, conversion, local early warning, and reporting. The gateway does not perform a safety shutdown; high-temperature or high-vibration events enter the deterministic interlock in the PLC/SIS or a human-response path. The SQLite cache window is calculated from the outage objective and disk budget rather than copying a fixed "24 hours."

The MEMS accelerometer outputs vibration acceleration (g), while industrial vibration limits are usually given as velocity, so the gateway integrates the acceleration signal once locally, converts it into a velocity value (mm/s), and only then compares it against the threshold. Local thresholds are split into two levels: an instantaneous vibration velocity above 10 mm/s or a temperature above 90 °C triggers an emergency shutdown; vibration velocity between 7 mm/s and 10 mm/s, or temperature between 80 °C and 90 °C, sends a pre-warning MQTT message to the cloud. This two-level threshold design is common on industrial sites — the hard threshold protects the equipment (with no dependence on AI), while the soft threshold goes to the cloud for deeper analysis.

Messaging layer: the cloud-side message queue is an Apache Kafka cluster (3-node deployment). The edge gateway's MQTT messages are bridged into Kafka through EMQX Edge. Kafka stores data partitioned by topic; uplink data (sensor readings) and downlink commands (remote threshold updates) travel on separate topics, achieving uplink/downlink isolation. This isolation matters greatly in scheduling — uplink traffic is voluminous and demands high throughput, while downlink commands are few but demand low latency and high reliability. The end-to-end message trace can follow a message's complete chain: sent from the device, arriving at the cloud access gateway, flowing through the message center, and being dispatched to each downstream consumer.

Cloud layer: a Kafka consumer service (a resident daemon written in Python) writes messages into the InfluxDB 3.x time-series database, with a retention policy of hot data (30 days, SSD) plus cold data (1 year, written into cloud object storage by downsampling tasks). The AI service pulls historical window data from InfluxDB and scores each device's latest data with an Isolation Forest model. Alarm events scoring below the threshold are pushed through Kafka's alarm-events topic to the alarm service, which in turn calls an SMTP gateway and a third-party SMS API. Grafana dashboards display real-time curves, historical trends, and the anomaly event list.

Figure 5-13 Four-Layer Factory Equipment Monitoring (Example)

Hardware and Software Selection

Table 5-5 lists all the hardware devices and software stacks used in this case, every one of them an open-source or commercially friendly-licensed component. The selection principles: on the factory floor, prefer proven and reliable Modbus devices; use a standard x86 industrial PC as the edge gateway to avoid software compatibility problems on the ARM architecture; and for cloud-layer components, pick a time-series database and visualization tools with active communities.

Layer	Component	Model/Name	Role	Notes
Device layer	Three-axis accelerometer	MEMS capacitive accelerometer (example model)	Captures X/Y/Z-axis vibration acceleration (g)	Digital Modbus RTU output; the gateway integrates it into velocity (mm/s)
Device layer	Temperature sensor	PT100 platinum RTD + transmitter	Captures bearing temperature (°C)	4–20 mA output, converted to Modbus RTU through A/D
Device layer	Modbus bus	RS-485	Connects sensors to the edge gateway	9600 bps, star topology
Edge layer	Edge gateway	Fanless x86 industrial PC (example configuration)	Runs Node-RED and Mosquitto	Intel Celeron N4100, 8GB RAM, 128GB SSD
Edge layer	MQTT broker	Mosquitto 2.x	Local message routing	MQTT v5.0 configured, persistent sessions
Edge layer	Rule engine	Node-RED 3.x	Protocol conversion, local threshold checks, local caching	Install node-red-contrib-modbus and node-red-contrib-sqlite
Edge layer	Local database	SQLite 3	Caches 24 hours of raw data	Single file, no separate service needed
Messaging layer	Message queue	Apache Kafka 3.x	Data buffering and decoupling, uplink/downlink isolation	At least a 3-node cluster, partitioned topics
Messaging layer	MQTT bridge	EMQX Enterprise / VerneMQ	Forwards edge MQTT messages to Kafka	Native MQTT-to-Kafka bridging supported
Cloud layer	Time-series database	InfluxDB 3.x	Stores sensor time-series data	Retention policy and downsampling tasks configured
Cloud layer	Visualization tool	Grafana 10.x	Dashboard display and alarm panels	Queries through the InfluxDB data source, with alarm rules and notifications configured
Cloud layer	AI inference framework	Python 3.10 + scikit-learn 1.3	Isolation Forest anomaly detection	Pre-trained model serialized as pkl, wrapped in a Python Flask REST API
Cloud layer	Notification service	Linux + sendmail + third-party SMS API	Sends email and SMS	SMS API billed monthly, email via a local SMTP relay
Cloud layer	Cloud server	Public-cloud virtual machine (example configuration)	Runs all cloud-layer components	4-core CPU, 16GB RAM, 100GB SSD + object storage

Table 5-5 Hardware and software selection for the factory equipment condition monitoring system

Cloud AI Anomaly Detection: From Industrial White Box to Data Black Box

Traditional industrial equipment alarming uses fixed thresholds — a bearing temperature limit of 90 °C, and the bell rings once it is exceeded. The limitation of this method is that it ignores the normal drift that comes with equipment aging. 80 °C is normal for a new motor; after two years of service, the same load may reach 85 °C, and a fixed threshold raises false alarms. The window that the Isolation Forest model fits is precisely this one — replacing the fixed threshold.

Model design and deployment: during initial system deployment, collect three consecutive days of data under normal operating conditions to build the training set. For each device, compute statistical features over hourly windows: median, variance, maximum, and minimum of the three vibration axes, plus median and variance of temperature. Train with scikit-learn's IsolationForest class, setting the contamination parameter to 'auto' — the training set comes from three consecutive days of normal operating conditions and should not preset an anomaly ratio in the first place; anomaly judgment is left to the downstream score threshold — and n_estimators=100.

The inference window is the latest 30 minutes, sliding every 5 minutes. Each inference computes the window's statistical features and feeds them into the model to obtain an anomaly score (score_samples); the lower the score, the more anomalous, with a default threshold of -0.5. Dropping below the threshold fires an alarm event. The model is retrained every 24 hours based on rolling-window data, and a separate thread loads the new model file, achieving zero-downtime updates.

The following pseudocode shows the key inference logic:

# Pseudocode: AI anomaly detection inference flow
def run_anomaly_detection(device_id, data_window):
    features = extract_features(data_window)
    score = model.score_samples([features])[0]
    if score < ANOMALY_THRESHOLD:
        alert_event = {
            "device": device_id,
            "score": score,
            "metric_values": features.tolist(),
            "alert_level": "critical"
        }
        kafka_producer.send('alarm-events', alert_event)
        return "ALERT_TRIGGERED"
    return "NORMAL"

This model replaces the traditional practice of nailing down a single threshold, turning alarm decisions from a hard boundary into a matter of statistical anomaly. Engineers can switch devices, review historical curves, and confirm or dismiss alarms from the Grafana panels at any time, forming a closed loop of human-machine collaborative anomaly response.

Edge Data-Flow Engineering Points

Beyond the architecture, the places where implementation most easily goes wrong concentrate in data-flow handling; three of them are listed here.

First, time semantics. Modbus RTU is a half-duplex bus whose polling delay depends on baud rate, frame length, slave response, silent interval, retries, and device count; it cannot be summarized as “millisecond-level.” If a sensor provides a sampling time under a known synchronization contract, preserve it, and let the gateway add Date.now() as receive or poll time. Gateway time cannot stand in for the instant at which vibration was sampled. Their offset and clock quality belong in data-quality fields.

Second, cache backfill. An edge-to-cloud outage does not automatically roll back a Kafka consumer offset; local SQLite replay and the cloud Kafka consumer position are two separate state domains. Backfill should assign every sample a stable event ID, replay in acquisition-time order, deduplicate idempotently in the cloud, and retain a backfill flag. Whether the Kafka consumer rereads data depends on commit, rebalance, and recovery policies and should be monitored separately.

Third, uplink/downlink isolation must appear in topics, quotas, consumers, and permissions. alarm-command can be separated from uplink data, but its partition count and retention cannot be preset as “one or two is enough.” Derive them from command keys, ordering, consumer parallelism, recovery, and measured throughput. A threshold-change message also carries a version, authorized principal, expiry, and signature or trusted provenance; the edge validates it, applies it through a controlled update, and returns the result. Mosquitto receipt must not directly rewrite a Node-RED rule.

Interaction Design for Alarming and Visualization

The Grafana dashboard is designed around engineers' working habits and divided into four core panels.

• Real-time curve panel: at the top, the latest 30 minutes of three-axis vibration curves, with anomaly points marked by solid red dots. The Y axis is in mm/s, queried from InfluxDB.
• Historical trend panel: below, each device's average vibration over the past 7 days (aggregated hourly), displayed as color-graded Stat charts; engineers can switch between devices.
• Alarm event panel: the Logs panel on the right, listing the last 24 hours of alarms with time, device number, anomaly score, and level (pre-warning / critical). Engineers click an annotate button to mark an alarm as acknowledged.
• Device status panel: at the bottom left, one small square per device — green for no alarms within 24 hours, yellow for pre-warning, red for critical. Clicking a square jumps to that device's real-time curve panel.

Grafana's alarm rules are configured as follows: based on the alarm events in alarm-events, trigger when new events' scores of scores < -0.5 persist for more than 15 minutes. The notification template contains the device name, metric values, and a panel link. Email is sent through SMTP; SMS calls a third-party API through a Webhook. If more devices are added in the future, devices can be grouped in Grafana and filtered quickly through the var-group variable.

Summary

This illustrative case places an edge gateway, MQTT, Kafka, storage, anomaly detection, and visualization in one pipeline to show how interface contracts, time semantics, and failure recovery fit together. It is not IoT DC3's current topology, and it provides no controlled experiment sufficient to prove that Isolation Forest reduces the false-positive rate. An implementation should first establish a fixed-threshold baseline and a versioned evaluation set, then compare false positives, false negatives, detection lead time, and operating cost. Safety shutdown remains the responsibility of the PLC/SIS.

5.6.2 An Engineering Checklist: Key Considerations in Platform-Layer Design

The factory case in Section 5.6.1 strings together a complete chain, but a solution that holds on paper does not mean a trouble-free launch. Many IoT projects run smoothly through the POC stage, only to expose connection drops, data loss, and exploding query latency once deployed at scale; the root cause is usually not a single wrong component choice but constraint conditions left unaligned across stages during design. This subsection assembles an engineering checklist covering the five key layers from device access to AI inference, for you to verify item by item during solution reviews or system design.

Device Access and Protocol Selection

• Protocol compatibility: confirm the lowest common protocol version across all sensors/actuators. For example, if the field supports Modbus RTU and RTU over TCP, the gateway must include both serial and Ethernet drivers. If OPC UA devices are present, evaluate whether the gateway supports client/server mode and the accompanying security certificates.
• Connection keep-alive: do the device-side SDK or MQTT clients implement heartbeat, automatic reconnection, and clean-session policies? Especially under MQTT QoS 1, confirm that the client correctly handles messages already sent but not acknowledged after reconnection.
• Uplink/downlink isolation: as described in Section 5.2.2, uplink (device → cloud) and downlink (cloud → device) should use different message-queue topics or channels, so that an uplink flood does not block dispatched control commands.

Message Queue Capacity and High Availability

• Peak-throughput estimation: do not look only at average reporting frequency. Build a model from device count, points per report, normal and worst-case rate, synchronized triggers, backfill, and retries; a 1.5–2× burst multiplier is only a case assumption to validate. Carry “message TPS → point-write rate → network and replica amplification → disk → consumers and partitions” into the resource budget, then test it with real key distributions and failures.
• Persistence and replication: acknowledgment and replication semantics differ across messaging systems; there is no universal rule that every queue uses acks=all and at least two replicas. In Kafka, design acks, replication factor, min.insync.replicas, unclean leader election, and failure-domain placement together, then validate the acceptable loss window and recovery objective.
• Failed-message disposition: for malformed or persistently failing messages that may be skipped, design an isolation queue, retry limit, and manual disposition; also identify ordering-sensitive messages that cannot simply be bypassed. A DLQ can isolate some poison messages but does not repair the consumer, schema, or downstream service automatically.

Capacity estimation does not have to wait for the architecture review. Take the 30-motor scale of Section 5.6.1 as an example, where each device reports one reading set every 10 seconds (three-axis vibration plus temperature, 4 fields in total); this chain can be computed from the device all the way down to the disk:

Step	Computation	Result for this example
Average message TPS	30 devices ÷ 1 reading set per 10 seconds	3 messages/s (12 data points/s)
Test burst ingress	3 messages/s × illustrative 2× burst factor	Start testing at 6 messages/s and 24 points/s, then revise from measured backfill and reconnect behavior
Application-payload lower bound	6 messages/s × illustrative 200 B/message	About 1.2 KB/s; excludes protocol headers, TLS, retries, broker replication, and observability traffic
Kafka partition count	Determined by keys, ordering, consumer parallelism, and recovery	Cannot infer three partitions from 6 messages/s; compare skew, rebalance, and recovery across candidate counts
Time-series point ingress	Test target of 24 points/s	Batch size follows latency and request bytes; only a target-engine benchmark can identify the bottleneck
Logical points per day	12 points/s × 86,400 s	About 1.04 million points; disk also includes measured bytes/point, indexes, WAL, compaction space, replicas, and backups

The table exists to expose units, omissions, and test entry points, not to declare that a small system has “almost zero” capacity risk. Even at a low average load, broken retry logic, synchronized reconnects, a hot key, disk pauses, or downstream failure can create a peak. Write conclusions as benchmark pass/fail criteria and recompute them whenever devices, firmware, topology, or retention changes.

Time-Series Database Retention Policies and Query Patterns

• Write throughput and batching: writes and queries compete for CPU, memory, WAL, disk, and network; do not presume which ceiling is higher. Batching commonly amortizes request overhead, but choose batch bytes from latency, server limits, retry cost, and tests rather than a universal “hundreds to thousands of points” minimum.
• Retention policy and downsampling: confirm how long raw data is retained, and whether it is automatically deleted or downsampled to minute/hour-level granularity afterward. Without a downsampling plan, historical queries a year later may be slower than writes.
• Deriving index design from query patterns: list frequent and expensive queries before deployment, then design against the target database's index, partition, and cardinality model. Whether device ID belongs in a tag, column, primary key, or partition key depends on the product. Validate with EXPLAIN, scanned bytes, and target-scale data rather than applying a Tag/Field slogan across products.

Edge Node Deployment and Remote Management

• Physical security and power supply: does the site hosting the edge gateway involve high temperature, dust, or vibration? Is a wide-temperature device or industrial-grade protection needed? How does the system recover automatically after a power loss? These decide an edge node's survival rate sooner than software configuration does.
• Remote operations channel: once an edge node is deployed, it needs controlled diagnostics, but SSH or an arbitrary reverse proxy should not be exposed by default. Prefer device identity, least privilege, short-lived credentials, mutual authentication, audited operations, and revocable sessions; where a shell is necessary, restrict its source and commands. OTA packages need signature verification, staged rollout, atomic switching, and a rehearsed rollback appropriate to the hardware and boot chain.
• Local caching and synchronization strategy: during a network interruption, the edge node should be able to cache a bounded amount of raw data (example: using a ring buffer or SQLite) and backfill it in timestamp order once the network recovers. Otherwise a single network blip can break data integrity.

AI Model Updates and Rollback

• Model version management: in the cloud, keep each model's version number, training-data date, feature-column list, and evaluation metrics (accuracy/recall, etc.). When replacing an edge model, it must carry a version tag for traceability.
• Edge-model release: full packages, differential packages, and weight-only updates each have trade-offs; a differential is not inherently more reliable. Whichever format is used, verify signature, hash, dependencies, disk space, and target-hardware compatibility, test a small cohort, switch atomically, and retain a bootable known-good version.
• Rollback criteria: false positives and false negatives are knowable only with labels or proxy measures, so “N alarms in a row” or “no alarms” cannot mechanically trigger rollback. Predefine stop conditions for data drift, runtime errors, latency, resources, human rejection, and safety events. Automatic or manual rollback passes through deterministic release control, while the edge may use only a preapproved fallback policy when disconnected.

Figure 5-14 Platform-Layer Engineering Check Matrix

One point worth stressing: the checklist is not a one-time document. As devices come up for renewal, message throughput grows, and new machine models enter production, the status of every check item changes. Plan to re-run the whole table every six months or after every system architecture change, updating it alongside the selection table from the Section 5.6.1 case — that is what keeps the platform layer running inside its design boundaries.

Table 5-6 Engineering checklist for platform-layer design

Layer	Key check item	Suggested check method	Common mistake
Device access and protocol selection	Protocol version compatible with gateway drivers	Use a simulator to send frames from multiple protocol versions and verify the gateway's parsing results	Only standard frames tested; frames with extension or error flags never tested
	Connection keep-alive and reconnection strategy	Cut the network for 5 minutes, then restore it and check whether the device reconnects within 30 seconds	After reconnecting, the device bursts its entire cache at once and overwhelms the cloud gateway
	Uplink/downlink topic isolation	Use the message trace to see whether uplink floods affect downlink command latency	Uplink and downlink mixed into one topic; control-command latency spikes to seconds
Message queue	Peak TPS matched to partition count	Simulate a device fleet with a load-testing tool (such as JMeter/MQTTX)	Partition count = consumer count - 1, leaving one partition without a consumer
	Message persistence and replication factor	Stop one broker node and check whether consumers keep consuming	Replication factor = 1; a single node going down loses data
	Dead-letter queue configuration	Produce one malformed message and watch whether it enters the DLQ	No DLQ configured; the bad message blocks the consumer group
Time-series database	Write batch size	Capture packets at the write side and check whether batches are ≥500 points	One-point writes; TPS never saturates but IOPS are already exhausted
	Retention policy (RP) and downsampling	Check whether the RP automatically deletes old data and whether the downsampling CQ is running	Raw data swells past the disk and query performance plummets
	Query-derived index design	List the top 5 queries and check whether they hit the tag index	Device ID put into a field instead of a tag; per-device filtering becomes a full-table scan
Edge node	Physical security and power supply	Check whether the watchdog is enabled; test automatic restart after a power cut	No watchdog; a frozen gateway needs an on-site manual reboot
	Remote operations channel and OTA	Simulate an upgrade failure and verify automatic rollback	OTA has no signature verification; a man-in-the-middle attack can inject malicious firmware
	Local cache and backfill	Cut the network for 30 minutes, restore it, and check the logs for missing data	Cache has no cap; a long outage fills the disk
AI model updates	Version management and tags	Check version number, feature columns, and training date in the model registry	New and old models confused; no way to trace which version caused the false alarms
	Differential deployment	Compare the bandwidth consumption of full pushes versus incremental pushes	Full model file pushed every time; many edge nodes updating at once congests the network
	Automatic rollback triggers	Monitor the false-alarm rate after deployment; check whether exceeding the threshold triggers an automatic switch	The model keeps degrading unnoticed; false alarms drown the operations team

5.6.3 Further Reading and Recommended Tools

After finishing this chapter, if you want to dig deeper into concrete platform-layer implementations, the tools and materials below deserve your time. They are not a theoretical list — they are engineering know-how you can load directly into your next project.

Open-Source Projects: Device, Edge, and Cloud in One Sweep

• Kubernetes (K8s) and KubeEdge
  Kubernetes is the benchmark for container orchestration in the cloud-native era. When your IoT data pipeline runs in the cloud, K8s handles automated deployment, service discovery, and elastic scaling. KubeEdge extends this capability to the edge: edge nodes keep running offline while the cloud manages them centrally — exactly the containerized form of the edge-cloud collaboration discussed in Section 5.3. A practical path: set up a single-machine environment with minikube or kind first, then try KubeEdge's cloud–edge networking.

• Prometheus and Grafana
  Prometheus is a monitoring and alerting system designed for time-series data; its pull model and the PromQL query language suit real-time collection of device metrics and rule-based evaluation. Grafana connects to data sources such as Prometheus and InfluxDB and is the see-it-all-on-one-screen visualization tool. The dashboard in the Section 5.6.1 factory case rests on exactly this pair.

• Eclipse Mosquitto
  One of the most widely deployed open-source MQTT brokers. Lightweight and stable, it suits local message relaying on edge hardware such as a Raspberry Pi. Paired with Node-RED, you can assemble a prototype link from Modbus to MQTT in ten-odd minutes.

• IoT DC3
  The open-source industrial IoT platform cited throughout this chapter. The current code organizes Drivers alongside centers such as Gateway, Auth, Manager, Data, and Agentic, joining point values, commands, and receipts through gRPC business registration and messaging ports. It is useful for studying device access, metadata, and message contracts. Rule orchestration, model inference, time-series backends, and deployment topology must each be checked at the selected commit rather than inferred from the project name or an old diagram.

These tools horizontally cover the complete pipeline from device access to visualization. A layered tool-chain diagram sums up how they relate:

Figure 5-15 Platform-Layer Toolchain Panorama

Deep Reading: Three Books Worth Opening

• Time-Series Databases: Principles and Practice: from LSM-trees and inverted indexes to InfluxDB's TSM engine and TimescaleDB's hypertable partitioning (discussed in Section 5.4). For readers who want to push write performance and downsampling schemes further.

• IoT System Architecture and Edge Computing (2nd edition): covers the full stack from physical sensors to cloud data analytics, overlapping heavily with this chapter's edge-cloud collaboration theme. Its chapters on telecommunication signaling and remote communication help you bridge the underlying network and the platform layer.

• Enterprise IoT Design: uses industrial cases such as Bosch Rexroth as its thread, telling the real journey of predictive maintenance and condition monitoring from theory to deployment. Its architecture diagrams and case details will deepen your understanding of anomaly detection and the alarm pipeline.

Online Learning and Communities

• The Coursera specialization: Internet of Things Specialization (from the University of California, Irvine): hands-on labs spanning sensing, networking, and data analysis — good for systematically filling knowledge gaps.

• The LF Edge projects: specifications and reference implementations for several edge-computing frameworks, including KubeEdge, EdgeX Foundry, and Open Horizon. The official site offers plenty of whitepapers and deployment guides — a window onto the industry's latest practice.

• The Grafana Labs blog and YouTube channel: practical cases covering everything from dashboard configuration to time-series query optimization, most of it open-source and reproducible.

One final reminder: you do not need to install every tool above. Pick one concrete scenario — equipment monitoring for a small factory, say — and walk the complete link from Mosquitto to InfluxDB to Grafana; then add one or two of the key books and a partial read of the DC3 source. That yields far more than blindly browsing a dozen projects.

With this, the Foundations part has completed its mission: from sensing, through the network, to the platform, a complete data foundation now lies on the page. The Technology part begins at Chapter 6, answering the next question — how this foundation is built, delivered, and operated.

In the cover’s terms, the Foundations part makes Sense hold up in engineering: the physical world has become trustworthy data. The remaining three words — Reason, Act, and Evolve — are fulfilled one by one in the Technology and Applications parts.