IoT Architectures, Models, and Requirements

Introduction

An Internet of Things (IoT) system connects physical objects to communication networks, computational resources, and applications that provide useful services. In electrical engineering, these objects may include smart meters, protection relays, photovoltaic inverters, motor drives, transformers, sensors, actuators, and building-management equipment. The engineering challenge is not simply to connect devices. It is to design an architecture that moves trustworthy data from the physical environment to useful decisions and, where necessary, returns safe control actions.

IoT architecture provides the structure for this design. It identifies where sensing, communication, computation, storage, security, control, and user interaction occur. Reference models provide a common vocabulary for comparing designs, while requirements define what the system must do and how well it must do it. A technically successful IoT design must therefore address both functional requirements—such as measuring voltage or switching a load—and non-functional requirements—such as latency, reliability, safety, interoperability, maintainability, and energy efficiency.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the roles of device, edge, gateway, platform, and application layers.
2. Distinguish IoT reference models from concrete implementations.
3. Compare device-to-device, edge, cloud, and hybrid deployment patterns.
4. Develop functional and non-functional requirements for smart electrical systems.
5. Analyze scalability, latency, reliability, safety, interoperability, maintainability, energy efficiency, and quality of service.
6. Apply an architecture and requirements process to an electrical-engineering case.

1. IoT Architecture as a System View

Architecture is a structured description of system elements, their responsibilities, interfaces, dependencies, and constraints. An IoT architecture is not necessarily a single physical stack. It is an analytical model that helps engineers allocate functions to suitable locations.

A typical information path is:

physical process → sensor or actuator → local processing → gateway or network → IoT platform → application or operator

The reverse path supports control:

application or control service → platform or gateway → actuator → physical process

This reverse path is especially important in electrical systems. A delayed temperature report may be inconvenient, but a delayed trip command, incorrect inverter setting, or unsafe remote switching operation can damage equipment or endanger people. Consequently, control functions with strict timing or safety requirements should not automatically be placed in a distant cloud.

A layered reference architecture

Figure: A practical layered view of an IoT system. Control commands may travel downward, while measurements and events commonly travel upward.

The layers in the figure are logical. A single industrial controller may implement device, edge, and gateway functions simultaneously. Conversely, a large utility may distribute platform functions across several data centres and services.

2. Principal Layers and Responsibilities

2.1 Device layer

The device layer interacts directly with the physical world. It includes sensors, meters, actuators, embedded processors, transducers, power supplies, and local firmware.

A sensor converts a physical quantity into a measurable signal. Examples include current transformers, voltage sensors, thermocouples, accelerometers, light sensors, and partial-discharge detectors. An actuator changes the physical system, as in a relay, contactor, valve, motor drive, inverter, or circuit breaker.

Device design must consider measurement range, accuracy, resolution, sampling rate, calibration, isolation, electromagnetic compatibility, environmental protection, and fail-safe behaviour. For example, a temperature sensor for a transformer must tolerate the expected thermal range and electrical environment; a sensor intended for a hazardous installation may require suitable intrinsic-safety or enclosure provisions.

Devices often have limited processing power, memory, bandwidth, and energy. They should therefore perform only necessary local operations, such as debouncing, plausibility checks, scaling, timestamping, and conversion from analogue to digital form. Device identity and secure boot are important because a compromised device can inject false measurements or issue unsafe commands.

2.2 Edge layer

Edge computing places computation near the source or consumer of data. An edge node may be an industrial computer, programmable logic controller, intelligent relay, embedded Linux device, or local server. Its functions can include:

• filtering noise and removing duplicate data;
• detecting events and abnormal patterns;
• buffering data during network outages;
• executing local control logic;
• running machine-learning inference;
• enforcing safety interlocks; and
• reducing communication volume and response time.

Edge processing is valuable when communication to a remote platform is unavailable, expensive, slow, or unsafe for closed-loop control. It does not eliminate the need for central systems: historical analysis, fleet management, model training, and enterprise integration may remain platform functions.

2.3 Gateway layer

A gateway connects a local field network to another network or service domain. It may translate protocols such as Modbus, CAN, DNP3, IEC 61850, Bluetooth Low Energy, Zigbee, Wi-Fi, or Ethernet into MQTT, HTTPS, OPC UA, or another northbound interface.

Gateway responsibilities include protocol translation, address management, aggregation, buffering, time synchronization, access control, certificate handling, and network segmentation. A gateway should preserve important semantics during translation. For instance, it should not convert a protection event into an unlabelled numerical value that loses its quality flag, timestamp, source, or event priority.

The gateway is often a security boundary. It should restrict inbound connections, authenticate devices, validate messages, log administrative actions, and support controlled software updates. A gateway can also be a single point of failure, so critical installations may require redundancy or a local fallback mode.

2.4 Platform layer

The IoT platform provides shared services for devices and applications. Typical services are:

• device registry and digital identity;
• telemetry ingestion and message routing;
• time-series storage and metadata management;
• command delivery and acknowledgement;
• rules engines and event processing;
• dashboards and application programming interfaces (APIs);
• software and configuration management; and
• monitoring, auditing, and access control.

The platform may be hosted on premises, in a private cloud, in a public cloud, or across a hybrid arrangement. Platform design must address data ownership, jurisdiction, retention, backup, recovery, and vendor dependence. A platform is not merely a database: it is an operational environment that manages the complete device and data lifecycle.

2.5 Application layer

The application layer delivers user or organizational value. Examples include energy monitoring, demand response, predictive maintenance, fault location, street-light management, building automation, microgrid control, and asset-performance reporting.

Applications should expose information at an appropriate level of abstraction. An operator may need “feeder overload risk” rather than thousands of raw samples, while an engineer may need waveform data for investigation. Applications must also distinguish observation from control. A display-only permission should not permit a user to change relay settings.

3. Reference Models and Deployment Patterns

A reference model is a conceptual framework, not a mandatory product architecture. The commonly used three-layer model contains perception, network, and application layers. A five-layer model separates transport and processing, making the role of platforms more visible. The IoT World Forum model uses a more detailed progression from physical devices through connectivity, edge computing, data accumulation, data abstraction, applications, and collaboration or business processes.

These models are complementary. A three-layer model is easy to communicate; a five- or seven-layer model helps allocate engineering responsibilities. None of them guarantees security, safety, or interoperability. Those properties must be designed across all layers.

Common deployment patterns

Device-to-device: Devices communicate locally, often through a fieldbus or short-range network. This is useful for fast local coordination but may provide limited historical analysis and remote management.

Device-to-cloud: Devices communicate directly with a remote platform. This simplifies local infrastructure but can increase dependence on wide-area connectivity and may be unsuitable for time-critical control.

Gateway-mediated: Devices use a local gateway for translation, buffering, and security. This is common when legacy electrical equipment must be integrated.

Edge-cloud hybrid: Time-critical processing occurs locally, while long-term storage, fleet analytics, reporting, and model training occur centrally. This is often the most practical pattern for smart electrical systems.

Data plane and control plane

The data plane carries measurements, events, and status information. The control plane carries configuration, commands, identities, policies, and software updates. These planes have different risk profiles. Data loss may reduce visibility; an unauthorised control command may directly change physical behaviour. Architectures should therefore apply stronger authorization, confirmation, auditing, and sometimes physical interlocking to control operations.

4. From Stakeholder Needs to System Requirements

Requirements engineering converts stakeholder expectations into testable statements. Stakeholders may include plant operators, electrical engineers, maintenance personnel, safety officers, cybersecurity teams, regulators, asset owners, and affected members of the public.

A useful requirements process is:

1. Identify stakeholders and operational scenarios.
2. Define system boundaries and external interfaces.
3. Identify assets, hazards, data flows, and trust boundaries.
4. Write functional and non-functional requirements.
5. Prioritize requirements and resolve conflicts.
6. Define verification methods and acceptance criteria.
7. Trace requirements to architecture, implementation, and tests.
8. Review requirements as operating conditions and threats change.

A good requirement is specific, necessary, unambiguous, feasible, verifiable, traceable, and consistent. “The system shall be highly reliable” is a goal, not an adequate requirement. “The gateway shall buffer at least 30 minutes of measurements at the specified sampling rate during loss of the wide-area link” is testable, provided the sampling rate and storage assumptions are defined.

Functional requirements

Functional requirements describe behaviour or services. Examples include:

• The system shall measure three-phase RMS voltage and current at a defined interval.
• The device shall attach a UTC timestamp and quality flag to each measurement.
• The gateway shall translate approved Modbus registers into the defined MQTT topic structure.
• The platform shall retain five-minute energy data for seven years.
• The application shall generate an alarm when temperature exceeds the configured threshold for the configured duration.
• A command shall require authenticated authorization before being sent to an actuator.
• The system shall record command origin, time, target, result, and acknowledgement.

Functional requirements should define units, ranges, sampling conditions, command states, error behaviour, and data quality. “Real-time monitoring” is incomplete unless real-time is expressed as a measurable deadline.

Non-functional requirements

Non-functional requirements describe qualities and constraints. They often determine architecture more strongly than features do.

#### Scalability

Scalability concerns growth in devices, data rate, users, sites, and concurrent commands. If N devices each produce r messages per second, the nominal message rate is:

where R is messages per second, N is the number of devices, and r is the average message rate per device. If each message has b bytes, the application payload rate is:

where B is bytes per second. Protocol overhead, retransmissions, metadata, and bursts make actual capacity requirements larger than this nominal estimate. The formula assumes a stable average rate and does not represent peak traffic.

For example, 10,000 meters sending one 200-byte message every 10 seconds produce R = 10,000 × 0.1 = 1,000 messages/s and B = 1,000 × 200 = 200,000 bytes/s, approximately 1.6 Mbit/s before overhead. A design must additionally size for synchronized reporting, firmware updates, alarms, and retries.

#### Latency and timeliness

Latency is elapsed time between an originating event and the receipt or completion of a specified response. A useful end-to-end decomposition is:

Each term represents sensing, processing, queuing, network, service, and actuation delay. The terms must use the same unit, such as milliseconds. This additive model assumes a single defined path; parallel paths, retransmissions, and queueing variability require a more detailed model.

Requirements should specify a percentile or maximum where appropriate, such as “95% of status updates shall arrive within 2 s” or “a local trip decision shall complete within 20 ms under stated operating conditions.” Average latency alone can hide dangerous outliers.

#### Reliability and availability

Reliability is the probability that a system performs its required function for a stated period under stated conditions. Availability is the proportion of time a service is operational. For a repairable service with mean time between failures (MTBF) and mean time to repair (MTTR), a basic steady-state approximation is:

MTBF and MTTR must use the same time unit, and the approximation assumes stable failure and repair behaviour. It does not capture common-cause failures, planned maintenance, degraded operation, or data correctness.

Reliability also includes correct data and command behaviour. Redundant servers cannot compensate for a sensor that systematically reports incorrect values. Requirements should address data integrity, backup, recovery point, recovery time, graceful degradation, and offline operation.

#### Safety and cybersecurity

Safety protects people, equipment, and the environment from unacceptable physical harm. Cybersecurity protects confidentiality, integrity, availability, authenticity, and accountability. They overlap but are not identical. A system can be cybersecure yet physically unsafe if its control logic is poorly designed; it can be physically safe in normal operation yet vulnerable to unauthorized access.

Safety requirements may include independent interlocks, emergency-stop behaviour, safe states, isolation, voltage withstand, protective coordination, and fail-safe defaults. Cybersecurity requirements may include unique identities, least privilege, secure update, encryption in transit, network segmentation, vulnerability management, logging, and incident response.

A remote command should not bypass local protection. Safety functions should remain effective when communications fail, a platform is unavailable, or data is corrupted. Risk analysis methods such as hazard and operability study, failure mode and effects analysis, and threat modeling help expose unsafe assumptions.

#### Interoperability

Interoperability is the ability of systems to exchange and correctly use information. It has several dimensions:

• Technical: physical, network, and protocol compatibility.
• Syntactic: common message structure and encoding.
• Semantic: common meaning, units, scaling, timestamps, and quality indicators.
• Organizational: compatible procedures, responsibilities, and policies.

Standards such as MQTT, OPC UA, Modbus, DNP3, IEC 61850, IPv6, and common data models can support interoperability, but merely using a named protocol is insufficient. Engineers must document schemas, versioning, device capabilities, error codes, time bases, and conformance tests.

#### Maintainability and lifecycle

Maintainability is the ease and speed with which a system can be inspected, repaired, configured, updated, and retired. Requirements should cover diagnostics, logs, health indicators, replaceable components, remote update procedures, rollback, documentation, spare parts, and end-of-life migration.

A system that performs well during commissioning but cannot be updated securely over fifteen years is not maintainable. Configuration should be version-controlled, changes should be authorized, and field devices should report their firmware and configuration versions.

#### Energy efficiency

Battery-powered devices require careful energy budgeting. If a device consumes current I for active time t_a and sleep current I_s for sleep time t_s in each cycle, the average current is:

Currents are in amperes and times must use the same unit. This is an idealized cycle-average calculation; radio startup peaks, battery temperature, leakage, and conversion losses may require additional margin. Energy can be estimated by multiplying voltage by charge, or by integrating power over time. Reducing message frequency, using event-driven reporting, batching transmissions, and processing locally can improve battery life.

#### Quality of service

Quality of service (QoS) describes the service level delivered to data or commands. Relevant attributes include delivery assurance, ordering, timeliness, bandwidth, jitter, availability, and priority. QoS is multidimensional: a message may be delivered reliably but too late to be useful.

Requirements should classify traffic. A protection-related event may require local deterministic handling and high priority. Periodic energy data may tolerate seconds or minutes of delay. Firmware updates may use spare bandwidth but require strong integrity checks. Queue policies should prevent high-volume low-priority telemetry from starving alarms or control traffic.

5. Requirement Conflicts and Trade-offs

Architecture is a process of disciplined trade-off. Strong encryption and certificate validation add processing and communication overhead. Frequent measurements improve observability but consume bandwidth and energy. Centralization simplifies fleet management but creates dependency on connectivity. Edge autonomy reduces latency but increases local software complexity and maintenance needs.

Requirements should therefore be prioritized according to risk and value. A useful classification is:

• Mandatory: failure is unacceptable or violates law, safety, or contract.
• Essential: necessary for the intended operational service.
• Desirable: improves performance or usability but can be deferred.

Verification methods should be assigned early: inspection, analysis, demonstration, or test. For example, encryption configuration may be inspected and tested; latency requires measurement under representative load; safety behaviour requires controlled fault testing; scalability requires load and stress tests.

6. Applied Case: Illustrative Smart Campus Microgrid

The following is a fictional illustrative case.

Background and problem

A university campus operates a photovoltaic array, battery energy storage, diesel generator, laboratory loads, and several buildings. Existing meters use different protocols. Operators receive delayed information, cannot easily compare feeder energy, and lack confidence that remote commands will be acknowledged. The campus wants to reduce peak demand while preserving safety and essential loads.

Analysis

The system contains safety-critical local functions, including overcurrent protection, anti-islanding protection, battery limits, and emergency shutdown. These functions must not depend on a public cloud. However, the campus also needs historical data, forecasting, reports, maintenance alerts, and optimization across buildings.

Stakeholder requirements include:

• electricians need trustworthy measurements and local fallback;
• facility managers need dashboards and alarms;
• energy analysts need historical, time-aligned data;
• cybersecurity staff need identity, audit, and update controls;
• the utility requires specified interface behaviour; and
• students and staff must not be exposed to unsafe switching operations.

Architecture and solution

Each meter and inverter remains responsible for measurement validity and local protective functions. An industrial edge controller aggregates local data, performs quality checks, stores data during communication outages, and executes approved load-shedding logic. A gateway translates legacy protocols and separates the operational network from the campus enterprise network.

The platform stores time-series data, manages device identities, distributes configuration, and provides APIs. Applications display feeder loading, photovoltaic production, battery state of charge, alarms, and demand forecasts. Optimization recommendations are sent as proposed actions; automatic commands are restricted to approved operating envelopes and require local validation.

A representative command sequence is:

1. The application generates a proposed battery setpoint.
2. The platform authenticates the request and checks authorization.
3. The gateway forwards the request to the edge controller.
4. The edge controller checks voltage, state of charge, temperature, operating mode, and local interlocks.
5. The inverter accepts or rejects the command.
6. The result and measured response are recorded for audit.

Outcome

The design continues safe local operation during a cloud outage, reduces unnecessary telemetry through edge aggregation, and provides a consistent historical data model. Operators gain visibility without granting every user control authority. The principal engineering outcome is not a particular vendor platform; it is the deliberate allocation of functions according to timing, safety, connectivity, and lifecycle requirements.

Learning points

1. Safety-critical control should remain independent of remote availability.
2. Protocol translation must preserve meaning, quality, and time information.
3. Requirements must distinguish recommendations, commands, acknowledgements, and physical outcomes.
4. Hybrid edge-platform architectures often balance latency, resilience, and manageability.
5. A complete audit trail is part of trustworthy control, not an optional reporting feature.

7. Governance, Ethics, and Contemporary Developments

IoT systems collect data about homes, workplaces, equipment, and behaviour. Engineers should apply data minimization, purpose limitation, access control, retention limits, and transparency. Energy data may reveal occupancy patterns; employee or student data may raise privacy concerns. Consent, contractual authority, and applicable data-protection law must be considered.

Procurement should address software bills of materials, vulnerability disclosure, security-support duration, cloud portability, interface documentation, and supplier exit plans. Artificial intelligence can assist with anomaly detection, load forecasting, and predictive maintenance, but models should not silently replace protection logic. Training-data quality, false alarms, concept drift, explainability, and human oversight are important. AI-generated recommendations require bounded authority, validation, and safe fallback behaviour.

Contemporary IoT development emphasizes zero-trust principles, digital twins, time-sensitive networking, confidential computing, federated analytics, and lifecycle security. These technologies are useful only when they solve a defined requirement. A digital twin with inaccurate asset metadata does not improve engineering decisions, and a sophisticated analytics model cannot compensate for poor sensor calibration.

Best-Practice Checklist

Before approving an IoT architecture, ask:

• Are physical assets, trust boundaries, and failure consequences identified?
• Is each function assigned to device, edge, gateway, platform, or application for a clear reason?
• Are time, accuracy, data quality, and command semantics specified?
• Can essential safety and control functions operate without the cloud?
• Are peak traffic, outages, retries, and synchronized events included in capacity planning?
• Are identity, authorization, secure update, logging, and recovery designed from the beginning?
• Are protocols accompanied by semantic data models and conformance tests?
• Are energy budgets and maintenance over the complete asset life understood?
• Does every important requirement have a verification method and acceptance criterion?

Chapter Summary

IoT architecture organizes physical devices, edge computation, gateways, platforms, and applications into a coherent system. Reference models provide useful abstractions, but they do not prescribe one implementation or automatically provide security and safety. Device layers sense and act; edge layers provide local processing and autonomy; gateways connect and translate; platforms manage data and devices; and applications deliver operational value.

Effective requirements engineering begins with stakeholders, scenarios, assets, hazards, and interfaces. Functional requirements specify what the system does, while non-functional requirements specify qualities such as scalability, latency, reliability, safety, interoperability, maintainability, energy efficiency, and quality of service. These qualities interact and often conflict, so architecture requires explicit trade-offs and measurable acceptance criteria. In smart electrical systems, hybrid edge-platform designs are frequently appropriate because they combine local deterministic operation with centralized analytics and management. Safety, cybersecurity, privacy, lifecycle support, and responsible use of AI must be treated as architectural concerns rather than afterthoughts.

Key Terms

Architecture: A structured description of system elements, relationships, interfaces, and constraints.

Edge computing: Processing performed near the physical source or consumer of data.

Gateway: A system that connects networks and may translate protocols, aggregate data, and enforce security.

IoT platform: Shared services for identity, ingestion, storage, device management, analytics, and APIs.

Application layer: The layer that presents information, alarms, analytics, and control functions to users or organizations.

Reference model: A conceptual framework used to classify functions and relationships.

Functional requirement: A testable statement describing required system behaviour.

Non-functional requirement: A testable quality, constraint, or performance condition.

Latency: Elapsed time between an event and a defined response or observation.

Reliability: Probability of performing a required function for a stated period under stated conditions.

Availability: Proportion of time that a service is operational.

Interoperability: Ability of systems to exchange and correctly use information.

Quality of service: Characteristics such as delivery, priority, timeliness, bandwidth, and jitter.

Fail-safe state: A condition intended to minimize harm when a fault occurs.

Digital identity: A uniquely managed representation used to authenticate a device, user, or service.

Trust boundary: A boundary across which security assumptions change.

Telemetry: Measurements or status data sent from a device or system.

Maintainability: Ease and speed of inspection, repair, update, and lifecycle management.

Edge autonomy: Ability of local equipment to continue defined operation without remote services.

Requirements traceability: Ability to link requirements to design elements, implementation, and verification evidence.

Review Questions

Short Answer Questions

1. What are the principal responsibilities of an IoT gateway?
2. How does edge computing differ from cloud-only processing?
3. Distinguish functional and non-functional requirements, giving one example of each.
4. Why is semantic interoperability important in smart electrical systems?
5. Why should safety-critical control not depend solely on a remote platform?

Long Answer Questions

1. Explain the device, edge, gateway, platform, and application layers and discuss how they cooperate in a smart electrical system.
2. Compare device-to-cloud and edge-cloud hybrid architectures, including their advantages and limitations.
3. Develop a set of functional and non-functional requirements for an IoT-based transformer-monitoring system.
4. Discuss how latency, reliability, cybersecurity, and safety interact in remote electrical control.
5. Explain how maintainability, energy efficiency, and interoperability influence IoT architecture over the asset lifecycle.

Analytical / Application Questions

1. A system has 5,000 devices, each transmitting a 250-byte message every 20 seconds. Calculate the nominal message rate and payload data rate, ignoring protocol overhead. Then identify at least three factors that could make the required network capacity higher.
2. Design a layered architecture for a campus microgrid that must continue local protection during a wide-area network outage. Justify where measurement, control, storage, analytics, and user authorization should occur.
3. A battery-powered sensor is active for 0.2 s at 80 mA and sleeps for 9.8 s at 0.1 mA in each cycle. Calculate its ideal average current and discuss practical effects that could change battery life.

Multiple Choice Questions with Answers

Question 1

Which layer most directly interacts with sensors and actuators?

A. Device layer

B. Platform layer

C. Application layer

D. Business-process layer

Correct Answer: A. Device layer

Question 2

What is a primary reason for placing time-critical control at the edge?

A. To eliminate all cybersecurity requirements

B. To reduce dependence on remote-network latency and availability

C. To guarantee unlimited storage

D. To avoid using sensors

Correct Answer: B. To reduce dependence on remote-network latency and availability

Question 3

A gateway commonly performs which function?

A. Replacing all physical protection devices

B. Translating protocols and aggregating local data

C. Defining the laws of electricity

D. Removing timestamps from measurements

Correct Answer: B. Translating protocols and aggregating local data

Question 4

If 2,000 devices each send 0.5 messages per second, what is the nominal message rate?

A. 100 messages/s

B. 500 messages/s

C. 1,000 messages/s

D. 4,000 messages/s

Correct Answer: C. 1,000 messages/s

Question 5

Which statement is a non-functional requirement?

A. The device shall measure phase current.

B. The platform shall store energy data.

C. The gateway shall translate Modbus registers.

D. Ninety-five percent of updates shall arrive within 2 seconds.

Correct Answer: D. Ninety-five percent of updates shall arrive within 2 seconds.

Question 6

What does semantic interoperability concern?

A. Whether devices have the same colour

B. Whether exchanged data has consistent meaning, units, and quality information

C. Whether every device uses the same battery

D. Whether a platform has unlimited bandwidth

Correct Answer: B. Whether exchanged data has consistent meaning, units, and quality information

Question 7

For a repairable service, which expression is a basic approximation of steady-state availability?

A. MTTR ÷ MTBF

B. MTBF ÷ (MTBF + MTTR)

C. MTBF × MTTR

D. MTBF − MTTR

Correct Answer: B. MTBF ÷ (MTBF + MTTR)

Question 8

Which practice best supports secure remote control?

A. Allowing every user to issue commands

B. Removing command logs to save storage

C. Using authentication, authorization, local validation, and acknowledgement

D. Disabling local interlocks

Correct Answer: C. Using authentication, authorization, local validation, and acknowledgement

Question 9

A sensor is active at 80 mA for 0.2 s and asleep at 0.1 mA for 9.8 s per 10-second cycle. What is its ideal average current?

A. 0.10 mA

B. 1.70 mA

C. 8.00 mA

D. 16.00 mA

Correct Answer: B. 1.70 mA

Question 10

Which architecture best combines local autonomy with centralized historical analytics?

A. Edge-cloud hybrid

B. Sensor-free architecture

C. Application-only architecture

D. Unconnected device architecture

Correct Answer: A. Edge-cloud hybrid