Smart-Grid Architecture and Systems Engineering

Introduction and Context

A smart grid is not simply a conventional electric grid equipped with digital meters. It is a cyber-physical system in which electrical infrastructure, communication networks, computation, automation, markets, and human decision-making operate together. Its purpose is to improve reliability, efficiency, flexibility, security, sustainability, and customer participation while preserving the fundamental physical requirements of power-system operation.

The traditional power system was organized mainly as a one-way hierarchy: large generators supplied transmission networks, transmission supplied distribution networks, and distribution supplied customers. Modern systems are more dynamic. Distributed solar generation, battery energy storage, electric vehicles, flexible loads, microgrids, prosumers, automated markets, and cloud-based applications create bidirectional flows of electricity and information. Consequently, the grid must be engineered as a system of systems rather than as a collection of independent components.

This chapter develops the architectural and engineering foundations required to analyze smart grids. It explains domains, actors, layers, interfaces, reference models, interoperability, system boundaries, requirements, and lifecycle decisions. It also shows how architecture supports practical engineering decisions and helps expose risks that may remain hidden when electrical and digital systems are designed separately.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain the cyber-physical character of smart-grid systems.
2. Distinguish smart-grid domains, actors, interfaces, layers, and viewpoints.
3. Use reference models such as the Smart Grid Architecture Model (SGAM) to structure analysis.
4. Explain interoperability requirements and the role of important standards.
5. Apply system-of-systems engineering principles to smart-grid projects.
6. Analyze a smart-grid architecture using functional, information, communication, and physical perspectives.
7. Identify security, safety, privacy, regulatory, and governance implications.

1. The Smart Grid as a Cyber-Physical System

A power grid contains physical energy assets—generators, transformers, lines, breakers, inverters, meters, and loads. A smart grid adds sensing, communications, software, control algorithms, and organizational processes. These digital elements observe and influence the physical system, while physical conditions constrain digital decisions.

For example, a voltage-control application may obtain measurements from field devices, estimate network conditions, calculate a control action, and send a set point to an inverter. The inverter then changes reactive-power output, which affects voltage. This is a feedback loop crossing several engineering domains.

A useful abstraction is:

This sequence is not necessarily instantaneous or centralized. Measurements may be delayed, data may be incomplete, communication may fail, and control actions may be executed locally or remotely. Therefore, architecture must address both electrical behavior and information behavior.

1.1 Operational characteristics

Important characteristics of smart-grid systems include:

• Heterogeneity: equipment may come from different manufacturers and generations.
• Scale: systems range from household devices to continent-wide networks.
• Criticality: interruptions can affect health, safety, economies, and essential services.
• Real-time behavior: some functions require millisecond response, while others operate over days or months.
• Bidirectional interaction: customers may consume, produce, store, and actively manage electricity.
• Evolution: assets and software are upgraded over decades rather than replaced at once.
• Regulatory dependence: technical design is constrained by market rules, privacy law, safety codes, and reliability requirements.

A successful architecture must therefore balance performance, cost, resilience, openness, maintainability, and security.

2. Domains, Actors, and Boundaries

2.1 Functional domains

A commonly used conceptual division identifies the following domains:

These domains are analytical categories, not necessarily separate organizations. A distribution utility may also operate a market platform, and an aggregator may coordinate customer resources across several domains.

2.2 Actors

An actor is a person, organization, device, software application, or system that participates in a function or exchanges information. Examples include:

• transmission-system operators;
• distribution-system operators;
• generators and independent power producers;
• aggregators of distributed energy resources;
• retailers and electricity markets;
• customers and prosumers;
• manufacturers and maintenance contractors;
• regulators and standards bodies;
• communication and cloud-service providers;
• protection relays, intelligent electronic devices, meters, sensors, and controllers.

Actors should not be confused with physical equipment. A substation may contain many devices, but the actor responsible for operating it could be a utility organization. Conversely, a software agent may perform a function on behalf of an actor.

2.3 System boundaries

Architecture analysis begins by defining the system of interest. A project might include only a feeder automation system, or it might include customer devices, market interfaces, telecommunications, utility operations, and regulatory reporting.

A boundary should identify:

1. components inside the system;
2. external systems and actors;
3. exchanged information and energy;
4. responsibilities at interfaces;
5. assumptions about timing, ownership, and trust.

Poorly defined boundaries cause requirements gaps. For example, a demand-response project may specify a utility command but fail to define who verifies customer response, who settles payments, or what happens when the communication network is unavailable.

3. Architectural Layers and Viewpoints

No single layer decomposition is universally correct. Different models serve different purposes. A practical architecture distinguishes at least four interacting viewpoints.

3.1 Physical or energy layer

This layer contains the electrical infrastructure and physical environment: generators, lines, transformers, switches, loads, storage, weather, and power-electronic interfaces. It is governed by electrical laws and operational constraints such as voltage limits, thermal ratings, frequency stability, and protection coordination.

3.2 Communication layer

The communication layer transports information among devices, applications, and organizations. It includes wired and wireless networks, routers, protocols, gateways, time synchronization, addressing, and network management. Communication quality is characterized by latency, bandwidth, jitter, availability, loss rate, and cybersecurity controls.

3.3 Information layer

This layer defines the meaning and structure of exchanged information. A measurement is not interoperable merely because it can be transmitted. Its unit, timestamp, quality flag, source, accuracy, and semantic meaning must also be understood.

For instance, “voltage” may refer to phase-to-neutral RMS voltage, phase-to-phase RMS voltage, instantaneous voltage, or a calculated average. An information model must distinguish these meanings.

3.4 Function and business layer

The function layer describes capabilities such as fault detection, outage restoration, voltage optimization, energy management, and market settlement. The business layer adds objectives, policies, roles, contracts, regulations, and performance measures.

The same device can support different functions. A battery may provide energy arbitrage, frequency response, backup power, local voltage support, or congestion relief. The architecture must identify how these services are coordinated when their requirements conflict.

3.5 Cross-layer relationships

Layers are analytically distinct but operationally coupled. A business requirement for rapid frequency support becomes a functional requirement for automatic control, an information requirement for high-quality frequency measurements, a communication requirement for bounded latency, and a physical requirement for sufficient inverter or generator capability.

A useful requirements chain is:

This chain prevents a common error: specifying a communication technology before identifying the required function and its timing, reliability, and security needs.

Figure: A layered view of smart-grid architecture. Requirements propagate downward, while measurements and operational feedback propagate upward.

4. Reference Models for Smart-Grid Architecture

A reference model is a structured abstraction that helps engineers describe a complex system consistently. It is not a final design and does not prescribe one implementation.

4.1 Smart Grid Architecture Model

The Smart Grid Architecture Model (SGAM) is widely used to represent smart-grid use cases across three dimensions:

1. Domains: generation, transmission, distribution, distributed energy resources, customer premises, and related areas.
2. Zones: process, field, station, operation, enterprise, and market.
3. Interoperability layers: component, communication, information, function, and business.

The zones represent increasing levels of abstraction and operational scope. The process zone is close to the physical process; the field zone contains sensors and actuators; the station zone contains local automation; the operation zone includes control-center systems; enterprise and market zones represent organizational and commercial activity.

SGAM is useful for locating interfaces and identifying missing responsibilities. For example, a voltage-control use case can be mapped from a distribution feeder sensor in the field zone, through a communication network, to a distribution-management application in the operation zone, with business constraints defined at the enterprise level.

4.2 Other useful reference perspectives

The NIST Smart Grid conceptual model emphasizes domains and information flows among generation, transmission, distribution, customers, operations, markets, and service providers. It is valuable for high-level stakeholder and interface analysis.

The OSI model is primarily a communication reference model. It helps separate application, transport, network, link, and physical communication concerns, but it does not by itself describe electrical functions or market responsibilities.

The systems engineering V-model structures lifecycle activities. Stakeholder needs and system requirements are progressively decomposed into architecture and detailed design, then integrated and verified in the reverse direction.

These models are complementary. A project may use a domain model to identify actors, SGAM to map interoperability, OSI concepts to analyze communications, and the V-model to organize development and testing.

5. Interoperability and Interfaces

5.1 Meaning of interoperability

Interoperability is the ability of systems or components to exchange information and use the exchanged information effectively. It has several levels:

• Technical interoperability: signals can be transmitted and received.
• Syntactic interoperability: data structures and formats are compatible.
• Semantic interoperability: the meaning of data is shared.
• Organizational interoperability: procedures, responsibilities, and policies align.
• Legal and commercial interoperability: contracts, regulations, tariffs, and settlement rules support the interaction.

A system can be technically connected but operationally non-interoperable. For example, two systems may exchange a numerical value but disagree about whether it is in volts or kilovolts, whether it is instantaneous or averaged, or whether a timestamp is in coordinated universal time.

5.2 Interface specification

An interface should specify more than a protocol name. A complete interface description should include:

• participating actors and responsibilities;
• information objects and their semantics;
• units, ranges, precision, timestamps, and quality indicators;
• communication pattern, such as request-response, publish-subscribe, or event notification;
• timing and performance requirements;
• authentication, authorization, encryption, and audit requirements;
• failure behavior and recovery procedures;
• versioning and backward compatibility;
• ownership, governance, and test responsibility.

5.3 Important standards and frameworks

Several standards families are particularly relevant:

• IEC 61850: communication networks and systems for power utility automation, including substation automation and abstract communication services.
• IEC 60870-5-104: telecontrol communication widely used in power-system supervisory applications.
• IEC 61968 and IEC 61970: Common Information Model (CIM) standards for utility enterprise integration and transmission/distribution management information.
• IEC 62351: security for power-system control operations and related communications.
• IEEE 2030.5: an application-layer protocol supporting communication with distributed energy resources and customer energy devices.
• DLMS/COSEM: widely used approaches for electricity-meter data exchange and device modeling.
• OpenADR: a framework for automated demand-response communication.

Standards do not automatically guarantee interoperability. Profiles, optional features, implementation choices, certification, conformance testing, and operational agreements are also necessary.

5.4 Interface example: distributed battery coordination

Suppose an aggregator coordinates batteries for a distribution operator. The interface must define:

1. the available capacity and state-of-charge information;
2. the requested active-power or reactive-power service;
3. time intervals and ramp limits;
4. minimum state-of-charge constraints;
5. acknowledgement and execution status;
6. fallback behavior if the connection fails;
7. cybersecurity and authorization requirements;
8. settlement data and performance verification.

Without these details, the word “control” is ambiguous and unsafe.

6. Systems Engineering for Smart Grids

Systems engineering is an interdisciplinary approach for defining, developing, integrating, operating, and retiring systems while satisfying stakeholder needs and constraints.

6.1 Requirements engineering

Requirements should be clear, testable, traceable, and prioritized. A useful requirement identifies:

• the required capability;
• the responsible component or actor;
• operating conditions;
• performance limits;
• security and safety constraints;
• verification method.

Weak requirement: “The system shall respond quickly.”

Stronger requirement: “Under normal communication conditions, the feeder-voltage control function shall issue a validated control command within the specified response interval after receiving a valid measurement.”

The numerical interval must be determined by the use case and stability analysis rather than invented generically. Protection, local control, supervisory control, and market dispatch have very different timing requirements.

6.2 Functional decomposition

A complex objective should be decomposed into functions. For automated fault restoration, functions may include:

1. acquire breaker and fault-indicator data;
2. validate measurements;
3. detect and locate the fault;
4. determine safe switching actions;
5. check network constraints;
6. issue commands;
7. verify the resulting topology;
8. notify operators and record the event.

Each function can then be allocated to field devices, substations, control centers, or human operators.

6.3 Allocation and trade-offs

Functions may be centralized, distributed, or hybrid. Centralized control can provide a broad system view but depends on communications and a control center. Distributed control can respond locally and remain functional during communication loss but may have limited global information.

Architecture selection involves trade-offs among:

• response time;
• resilience and graceful degradation;
• computational capability;
• communication dependence;
• cost and maintainability;
• cybersecurity exposure;
• interoperability and vendor diversity;
• explainability and operator trust.

6.4 Verification and validation

Verification asks whether the system was built according to its specified requirements. Validation asks whether the resulting system solves the intended operational problem.

Methods include inspection, analysis, simulation, hardware-in-the-loop testing, factory acceptance testing, site acceptance testing, penetration testing, failover testing, and operational trials.

A smart-grid project should maintain traceability from stakeholder needs to requirements, design elements, test cases, and operational evidence. This is especially important when software updates alter behavior after commissioning.

7. Reliability, Resilience, Safety, and Security

Reliability concerns the ability to perform intended functions under stated conditions. Resilience concerns the ability to anticipate, withstand, adapt to, and recover from disruptive events. A reliable system may perform well during normal conditions but lack resilience against a coordinated cyberattack, severe storm, wildfire, or supply-chain disruption.

7.1 Defense in depth

Cybersecurity should use multiple protective layers:

• asset inventory and classification;
• network segmentation and controlled conduits;
• strong identity and access management;
• least privilege;
• secure configuration and patch management;
• encryption where appropriate;
• monitoring and anomaly detection;
• backups and recovery procedures;
• incident response and forensic capability;
• supplier and software assurance.

Security controls must respect availability and safety. An authentication mechanism that blocks an emergency trip function can create unacceptable risk. Security architecture therefore requires coordinated analysis with protection engineers and operators.

7.2 Safety and cyber-physical hazards

A cyber event may produce a physical hazard, such as inappropriate breaker operation, loss of voltage control, battery overheating, or unsafe islanding. Safety analysis should consider incorrect commands, stale data, sensor failure, communication loss, malicious data, and common-cause failures.

Protective functions should not depend unnecessarily on wide-area communications. Local protection and fail-safe behavior often provide an essential safety layer even when advanced automation is unavailable.

7.3 Privacy and ethics

Smart meters and customer energy-management systems can reveal occupancy patterns, appliance use, income-related behavior, or health-related routines. Data collection should follow purpose limitation, data minimization, access control, retention limits, transparency, and applicable privacy law.

Automated demand response may disproportionately affect customers who have less flexibility or less ability to understand tariffs. Fairness, accessibility, informed consent, and dispute mechanisms should be included in system governance.

8. Quantitative Performance Measures

Architecture decisions should be supported by measurable criteria. Common measures include availability, latency, data quality, restoration time, forecast error, and renewable-energy curtailment.

For a component with mean time between failures (MTBF) and mean time to repair (MTTR), a simple steady-state availability approximation is:

Here, MTBF and MTTR must use the same time unit. This approximation assumes statistically stable behavior and that repair and failure processes are adequately represented by the two averages. It is not a complete reliability model for dependent, redundant, or time-varying systems.

For independent components in a series functional chain, a simplified availability estimate is:

where A_i is the availability of component i. This model assumes that all components are required, failures are independent, and common-cause failures are neglected. Redundancy and common-cause effects require more appropriate models.

Worked example: availability approximation

An automation communication gateway has MTBF = 8,000 h and MTTR = 10 h. Its approximate availability is:

Thus, the estimated availability is approximately 99.875%. This result does not mean that the gateway is suitable for every protection function: latency, deterministic behavior, cybersecurity, and failure mode also matter.

For two required independent components with availabilities 0.99875 and 0.99900:

The chain availability is lower than either individual availability because both components must operate. In real smart grids, redundant paths may improve availability, while shared power supplies, software defects, or common network infrastructure may reduce it.

9. Applied Case: Illustrative Feeder Flexibility Platform

This is an illustrative case rather than a report of a particular utility project.

Background

A distribution utility is experiencing midday overvoltage on a feeder with high rooftop photovoltaic penetration. It also faces evening congestion when customers charge electric vehicles. The utility wants to use batteries, flexible water heating, and managed vehicle charging instead of immediately upgrading the entire feeder.

Problem

The utility must coordinate customer-owned resources without compromising customer comfort, battery safety, privacy, or network limits. It must also distinguish a commercial flexibility service from emergency protection. A delayed or incorrect market instruction must not prevent local voltage protection from operating.

Analysis

The architecture identifies the following actors:

• distribution-system operator;
• aggregator;
• customers and prosumers;
• distributed-energy-resource controllers;
• meter-data and settlement systems;
• telecommunications provider;
• regulator and market operator.

The physical layer includes the feeder, transformer, photovoltaic systems, batteries, electric vehicles, and flexible loads. The information layer must represent availability, power capability, state of charge, customer constraints, timestamps, and quality. The communication layer must support authenticated commands, status reporting, and loss-of-communication behavior.

The use cases are divided by time and criticality. Local inverter voltage functions operate quickly and independently. The aggregator submits schedules over longer intervals. The utility monitors feeder conditions and sends flexibility requests when forecasts indicate congestion or voltage risk.

Approach and solution

The design uses a hybrid architecture:

1. Local controllers enforce safety, equipment limits, and basic voltage behavior.
2. The aggregator coordinates customer resources and translates utility requests into device-level actions.
3. The utility validates requested flexibility against feeder operating limits.
4. A common information model defines resource identity, capability, measurement quality, and status.
5. Commands are authenticated, authorized, logged, and assigned expiration times.
6. If communications fail, devices revert to predefined local schedules or safe default behavior.
7. Settlement uses measured response and documented baselines, with a dispute process.

Before deployment, the utility performs power-flow studies, communication tests, cybersecurity assessments, hardware-in-the-loop tests, and staged field trials.

Outcome

The architecture can reduce unnecessary feeder congestion while preserving a boundary between commercial flexibility and protection. Its success depends not only on control algorithms but also on clear responsibilities, data semantics, customer agreements, testing, and recovery procedures.

Learning points

• A device capability is not automatically a grid service; a service requires defined performance, authority, and settlement rules.
• Local safety functions should remain effective during communication failure.
• Interoperability requires shared meaning, not merely network connectivity.
• Architecture must include organizational and regulatory actors.
• Verification should test normal operation, degraded modes, malicious inputs, and recovery.

10. Contemporary Developments and Professional Practice

Current smart-grid engineering increasingly involves inverter-dominated power systems, edge computing, advanced distribution-management systems, digital substations, virtual power plants, transactive services, and artificial-intelligence applications.

AI can support load forecasting, fault classification, asset-health assessment, and anomaly detection. However, an AI model should not be treated as an autonomous authority merely because it performs well on historical data. Engineers must consider data drift, adversarial inputs, explainability, bias, uncertainty, human override, and fail-safe operation. AI recommendations should be integrated into a governed decision process with defined accountability.

Digital twins can combine asset models, real-time measurements, simulations, and maintenance information. Their value depends on model validity, data quality, synchronization, and lifecycle governance. A visually impressive digital twin that lacks validated interfaces or trustworthy data is not a reliable engineering tool.

Best practices include:

1. begin with use cases and stakeholder outcomes;
2. define system boundaries and dependencies explicitly;
3. separate safety-critical, operational, and commercial functions;
4. use reference models to expose interfaces;
5. specify information semantics and data quality;
6. design degraded modes before selecting technologies;
7. apply security and privacy throughout the lifecycle;
8. require conformance, interoperability, and cybersecurity testing;
9. maintain requirements and configuration traceability;
10. plan for upgrades, retirement, and supplier change.

Chapter Summary

Smart-grid architecture integrates electrical infrastructure with communications, information, software, markets, organizations, and human operators. The smart grid is therefore a cyber-physical system and a system of systems.

Architectural analysis benefits from distinguishing domains, actors, system boundaries, layers, and viewpoints. Physical, communication, information, function, and business layers are strongly coupled: a business objective becomes a function, an information exchange, a communication requirement, and a physical capability.

Reference models such as SGAM and the NIST conceptual model help organize complexity, while the OSI model and systems-engineering lifecycle provide complementary perspectives. Interoperability requires technical, syntactic, semantic, organizational, legal, and commercial alignment. Standards such as IEC 61850, IEC 61968/61970, IEC 62351, IEEE 2030.5, DLMS/COSEM, and OpenADR support particular interfaces but do not eliminate the need for profiles, testing, governance, and clear responsibilities.

Systems engineering provides a disciplined process for requirements, functional decomposition, allocation, integration, verification, and validation. Reliability and availability measures are useful but must be interpreted with their assumptions. Security, safety, privacy, resilience, fairness, and accountability must be designed into the architecture rather than added after deployment.

Key Terms

Cyber-physical system: A system in which computational and communication processes interact with physical processes.

Smart grid: An electricity system enhanced by sensing, communication, automation, computation, and coordinated decision-making.

System of systems: A set of independent systems that cooperate to provide capabilities not achieved by the systems separately.

Actor: A person, organization, device, application, or system participating in a function or information exchange.

Domain: A functional or organizational area such as generation, transmission, distribution, customer, or market.

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

Interoperability: The ability of systems to exchange and effectively use information.

Semantic interoperability: Agreement on the meaning, context, and interpretation of exchanged information.

Interface: A defined boundary across which systems, actors, energy, or information interact.

SGAM: Smart Grid Architecture Model, a multidimensional framework for mapping smart-grid use cases.

CIM: Common Information Model used to support standardized utility information exchange.

SCADA: Supervisory Control and Data Acquisition system for monitoring and controlling industrial processes.

Distributed energy resource: A relatively small generation, storage, or controllable resource connected near loads or within distribution networks.

Prosumer: A customer who both consumes and produces or exports electricity.

Resilience: The ability to withstand, adapt to, and recover from disruptive events.

Availability: The proportion of time a system is capable of performing its required function.

Verification: Confirmation that a system meets specified requirements.

Validation: Confirmation that a system fulfills its intended purpose in its operational context.

Defense in depth: Use of multiple, complementary security and protective layers.

Requirements traceability: The documented linkage among stakeholder needs, requirements, design, and verification evidence.

Review Questions

Short Answer Questions

1. Why is a smart grid considered a cyber-physical system?
2. Distinguish an actor from a physical device.
3. What is semantic interoperability?
4. Name the main layers used in a practical smart-grid architecture.
5. Differentiate verification from validation.

Long Answer Questions

1. Explain how a business objective propagates through functional, information, communication, and physical layers.
2. Compare the purposes of SGAM, the NIST smart-grid conceptual model, the OSI model, and the systems-engineering V-model.
3. Discuss why communication connectivity alone does not guarantee interoperability.
4. Explain how system boundaries and actor responsibilities influence smart-grid requirements.
5. Analyze the relationship among reliability, resilience, cybersecurity, and safety in a distribution automation system.

Analytical / Application Questions

1. Design a layered architecture for coordinating electric-vehicle charging on a constrained distribution feeder. Identify actors, interfaces, data, timing needs, failure behavior, and security controls.
2. A utility proposes centralizing all voltage control in a cloud application. Analyze the benefits, risks, and conditions under which a hybrid architecture would be preferable.
3. Using the availability approximation A = MTBF ÷ (MTBF + MTTR), compare a component with MTBF = 5,000 h and MTTR = 20 h with one having MTBF = 2,000 h and MTTR = 4 h. Explain why availability alone is insufficient for selecting a smart-grid control component.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly makes a smart grid a cyber-physical system?

A. It contains only high-voltage equipment.

B. Its computation and communications interact with physical electrical processes.

C. It eliminates the need for human operators.

D. It uses a single communication protocol.

Correct Answer: B. Its computation and communications interact with physical electrical processes.

Question 2

Which layer primarily defines the meaning, structure, units, and quality of exchanged data?

A. Physical energy layer

B. Communication layer

C. Information layer

D. Market layer

Correct Answer: C. Information layer

Question 3

What is the main purpose of a reference model such as SGAM?

A. To prescribe one mandatory hardware design

B. To organize complex systems, domains, zones, and interfaces

C. To replace all cybersecurity standards

D. To calculate short-circuit current

Correct Answer: B. To organize complex systems, domains, zones, and interfaces

Question 4

Which statement best describes semantic interoperability?

A. Devices use the same cable type.

B. Messages arrive at the destination.

C. Systems agree on the meaning and context of exchanged information.

D. All systems are manufactured by one company.

Correct Answer: C. Systems agree on the meaning and context of exchanged information.

Question 5

Which standard family is associated with the Common Information Model for utility information exchange?

A. IEC 61968/IEC 61970

B. IEC 62351 only

C. IEEE 802.11 only

D. IEC 60034

Correct Answer: A. IEC 61968/IEC 61970

Question 6

A requirement stating that a system shall respond 'quickly' is weak mainly because it is:

A. Too mathematically complex

B. Not measurable or sufficiently testable

C. Limited to physical equipment

D. Automatically unsafe

Correct Answer: B. Not measurable or sufficiently testable

Question 7

For a component with MTBF = 8,000 h and MTTR = 10 h, the approximate availability is:

A. 0.87500

B. 0.98750

C. 0.99875

D. 1.08750

Correct Answer: C. 0.99875

Question 8

Which practice is most consistent with defense in depth?

A. Using one very strong password for every device

B. Relying exclusively on a cloud firewall

C. Combining segmentation, access control, monitoring, recovery, and secure configuration

D. Disabling all remote monitoring

Correct Answer: C. Combining segmentation, access control, monitoring, recovery, and secure configuration

Question 9

In systems engineering, validation asks whether:

A. The system was assembled in the correct factory

B. The system fulfills its intended purpose in its operational context

C. Every component has identical availability

D. A protocol uses encryption

Correct Answer: B. The system fulfills its intended purpose in its operational context

Question 10

Why should local safety functions often remain effective during communication loss?

A. Local functions always cost less.

B. Communication loss can otherwise prevent essential protection or safe operation.

C. Central systems cannot process measurements.

D. Market settlement requires local control.

Correct Answer: B. Communication loss can otherwise prevent essential protection or safe operation.