Systems Engineering, Testing, and Lifecycle Management

Introduction

An IoT-enabled smart electrical system is not merely a collection of sensors, controllers, communication links, and software. It is a socio-technical system that must satisfy stakeholder needs throughout its life: conception, design, construction, commissioning, operation, maintenance, upgrade, and disposal. Examples include smart distribution substations, building energy-management systems, photovoltaic microgrids, electric-vehicle charging networks, and industrial monitoring platforms.

Such systems operate at the intersection of electrical engineering, embedded computing, communications, cybersecurity, data analytics, safety engineering, and asset management. A technically impressive prototype can still fail if it is difficult to maintain, insecure, incompatible with existing infrastructure, uneconomical, or unacceptable to users. Systems engineering provides a disciplined method for managing these interactions.

This chapter presents an end-to-end engineering process. It explains stakeholder analysis, requirements, architecture selection, prototyping, simulation, hardware-in-the-loop testing, verification, validation, commissioning, reliability, documentation, configuration management, sustainability, and decommissioning.

Learning Objectives

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

1. Identify stakeholders, needs, constraints, risks, and system requirements.
2. Compare IoT and smart-electrical architectures using technical and lifecycle criteria.
3. Distinguish verification from validation and design an appropriate test strategy.
4. Explain the roles of simulation, rapid prototyping, and hardware-in-the-loop testing.
5. Apply basic reliability and maintainability measures.
6. Prepare commissioning, documentation, configuration-control, and maintenance plans.
7. Evaluate cybersecurity, safety, ethical, regulatory, and sustainability issues.
8. Explain how a system should be retired and decommissioned responsibly.

1. Systems Engineering Perspective

Systems engineering is an interdisciplinary approach for developing and managing a system over its complete lifecycle. Its central principle is traceability: every important stakeholder need should lead to a requirement, a design decision, an implementation element, and one or more objective acceptance tests.

A useful lifecycle is:

Need identification → concept development → requirements → architecture → detailed design → implementation → integration → verification → validation → commissioning → operation and maintenance → retirement.

The stages are not strictly linear. Field data may reveal a requirement defect; maintenance experience may lead to a redesign; a cybersecurity event may require architecture revision. Therefore, practical projects use iterative or incremental development while preserving formal control of requirements and configurations.

1.1 Stakeholder analysis

Stakeholders include anyone who affects, uses, regulates, owns, maintains, is exposed to, or is affected by the system. For a smart substation, stakeholders may include the utility owner, protection engineers, control-room operators, field technicians, customers, equipment vendors, telecommunications providers, safety authorities, cybersecurity personnel, and the surrounding community.

Stakeholder analysis should identify:

• objectives and expected benefits;
• authority and decision rights;
• operational roles and user skills;
• safety, privacy, and security concerns;
• regulatory obligations;
• cost, schedule, and reliability expectations;
• interfaces with existing equipment and organizations.

A stakeholder register records these findings. Conflicting expectations must be made explicit. For example, an operations team may want remote access for convenience, while a cybersecurity team may require strict network isolation. The engineering solution should address the underlying needs rather than simply choosing one stakeholder over another.

1.2 Requirements engineering

A requirement states what the system shall do or what property it shall possess. Good requirements are specific, testable, necessary, feasible, unambiguous, and traceable. “The system shall provide reliable monitoring” is weak because “reliable” is not defined. A stronger requirement might be: “The monitoring gateway shall deliver a valid feeder-current measurement to the control platform at least once every 10 s during normal network operation.”

Requirements are commonly classified as:

Requirements should include acceptance criteria. A requirement for measurement accuracy, for example, must identify the operating range, reference instrument, uncertainty, temperature conditions, and pass/fail tolerance.

A requirements traceability matrix links stakeholder needs to system requirements, subsystem requirements, design elements, test cases, and results. It prevents both omission and uncontrolled addition of functionality.

2. Architecture Selection for Smart Electrical Systems

Architecture describes the major elements of a system and their relationships. In IoT electrical systems, architecture decisions include where sensing and control occur, how data move, how power and communications are isolated, and how the system behaves when connectivity is lost.

A typical layered architecture contains:

1. Physical layer: conductors, transformers, switchgear, sensors, actuators, meters, and power converters.
2. Device and control layer: microcontrollers, programmable logic controllers, protection relays, local control loops, and embedded diagnostics.
3. Connectivity layer: wired Ethernet, fieldbus, cellular, Wi-Fi, mesh radio, or optical links.
4. Edge and platform layer: gateways, protocol conversion, buffering, local analytics, time synchronization, and device management.
5. Application layer: dashboards, alarms, forecasting, asset analytics, demand response, and supervisory control.
6. Governance layer: identity, cybersecurity, data ownership, safety, compliance, and lifecycle management.

Layering improves modularity, but real systems may combine layers. A protective relay must make time-critical decisions locally rather than waiting for a cloud service. A cloud platform may be appropriate for fleet-level analytics but not for a protection trip whose safety depends on millisecond response.

2.1 Centralized, edge, and hybrid architectures

A centralized architecture simplifies fleet-wide data management and may reduce local hardware. It depends heavily on communication availability and can create a single point of failure. An edge architecture processes data close to the equipment, reducing latency and bandwidth use and improving operation during communication outages. It may increase local complexity and maintenance requirements. A hybrid architecture combines local safety-critical control with remote supervision and analytics and is often the most appropriate arrangement.

Architecture selection should consider:

• latency and determinism;
• availability and resilience;
• cybersecurity exposure;
• bandwidth and data cost;
• interoperability;
• computational and energy limits;
• maintainability and vendor dependence;
• expansion and technology obsolescence;
• total lifecycle cost.

A weighted decision matrix can compare alternatives. If alternative j receives score s_ij for criterion i, with criterion weight w_i, the weighted score is:

Here, w_i are non-negative normalized weights whose sum is 1, and s_ij are scores on a stated scale. The method supports structured comparison but does not replace engineering judgment; poor criteria or subjective scores can produce misleading results.

3. Modeling, Simulation, and Prototyping

Simulation allows engineers to examine behavior before installing equipment. Electrical-network simulation can represent load flow, short circuits, harmonics, transients, and renewable generation. Control simulation can examine feedback stability and response. Communication and software simulation can explore latency, packet loss, congestion, and failure recovery.

A model is useful only within its assumptions. A steady-state load-flow model cannot establish the performance of a protection algorithm during a fast transient. A battery model fitted at room temperature may not predict behavior at low temperature. Model parameters should therefore be documented, calibrated against measurements, and accompanied by uncertainty and validity limits.

3.1 Prototyping sequence

A sensible sequence is:

1. Develop a conceptual model and risk register.
2. Simulate key operating conditions and failure cases.
3. Build a low-cost proof of concept for uncertain interfaces.
4. Develop an engineering prototype using representative hardware.
5. Perform subsystem and integrated tests.
6. Conduct a pilot deployment under controlled conditions.
7. Release the production system only after acceptance criteria are met.

Rapid prototypes are valuable for learning, but prototype components should not be assumed to satisfy production requirements. In particular, breadboard wiring, consumer communication modules, unverified firmware, and temporary protective arrangements are unsuitable for unattended electrical installations.

3.2 Hardware-in-the-loop testing

Hardware-in-the-loop (HIL) testing connects real controllers, relays, meters, or gateways to a real-time simulator. The simulator represents the electrical plant or communication environment and exchanges signals with the device under test. HIL testing occupies an important position between software simulation and field testing.

For example, a real protection relay can receive simulated currents and voltages corresponding to faults at different locations. Its trip decision, timing, communications, and recovery behavior can then be evaluated without energizing a physical high-power network.

HIL tests should include:

• normal operation;
• sensor bias and saturation;
• missing, delayed, duplicated, or corrupted messages;
• communication loss and restoration;
• abnormal frequency and voltage;
• device restart and power interruption;
• cyber-relevant events such as invalid credentials or unauthorized commands;
• boundary values and combinations of faults.

The HIL model must have sufficient numerical accuracy, time resolution, and interface fidelity. A test that omits sensor dynamics or communication delay may produce unjustified confidence.

4. Verification, Validation, and Acceptance

Verification asks: “Was the system built according to its specified requirements?” It includes inspection, analysis, demonstration, and testing. Validation asks: “Does the system solve the stakeholder’s real problem in its intended environment?” A system may pass verification yet fail validation—for example, a dashboard may meet its software specification but present information too slowly for an operator during an emergency.

A verification plan should define:

• requirement identifier;
• verification method;
• test configuration;
• instruments and calibration status;
• environmental conditions;
• test procedure;
• expected result and acceptance limit;
• actual result, evidence, and reviewer;
• treatment of anomalies and retesting.

4.1 Test levels

Testing normally progresses through levels:

• Unit testing: individual software functions, circuits, or modules.
• Integration testing: interfaces between modules and subsystems.
• System testing: complete behavior against system requirements.
• Performance testing: response time, throughput, accuracy, capacity, and endurance.
• Environmental and EMC testing: temperature, humidity, vibration, emissions, and immunity as applicable.
• Safety testing: protective functions, isolation, interlocks, and fail-safe states.
• Security testing: authentication, authorization, vulnerability assessment, logging, and recovery.
• User acceptance testing: realistic workflows with representative users.
• Site acceptance testing: installed equipment, wiring, network, settings, and local conditions.

Testing must include negative cases. A smart switch should be tested not only when it receives a valid command but also when commands are malformed, conflicting, delayed, unauthorized, or received during a power interruption.

4.2 Commissioning

Commissioning is the controlled process of bringing an installed system into service. It includes inspection, point-to-point checks, sensor polarity and scaling checks, network validation, firmware and configuration confirmation, functional tests, alarm verification, failover tests, operator training, and formal handover.

Energization should proceed through approved hold points. Safety procedures must define isolation, lockout/tagout, switching authority, arc-flash controls, test equipment requirements, and emergency actions. Commissioning records become an essential baseline for later maintenance.

5. Reliability, Availability, and Maintainability

Reliability is the probability that an item performs its required function for a specified time under stated conditions. For a constant failure rate λ and statistically appropriate assumptions, the reliability function is:

Here, t is operating time and λ is the constant failure rate in inverse time. This exponential model is suitable for a useful-life period with approximately random failures; it is not generally appropriate for early-life defects or wear-out failures.

The mean time to failure for this model is:

For a repairable component with constant failure rate λ and repair rate μ, the idealized steady-state availability is:

Here, μ is the repair rate, equal to the reciprocal of mean time to repair under the same exponential assumptions. Availability is not the same as reliability: a system can be highly available because it is rapidly repaired even though it fails often.

For independent components in series, where every component must operate, system reliability is:

For independent components in parallel, where at least one component must operate:

These equations assume independence and clearly defined success criteria. Common-cause failures, shared power supplies, shared software, environmental stress, and human error can invalidate the simple results.

Worked example: series reliability

Two independent monitoring devices have one-year reliabilities of 0.98 and 0.97. If both are required for successful system operation:

R_system = 0.98 × 0.97 = 0.9506

Thus, the estimated one-year reliability is 0.9506, or 95.06%, under the stated independence assumption. If either device could independently maintain the monitoring function, the parallel reliability would be 1 − (1 − 0.98)(1 − 0.97) = 0.9994, or 99.94%, although the added device may introduce cost and common interfaces that reduce the practical benefit.

Reliability analysis methods

Failure Mode and Effects Analysis (FMEA) examines component failure modes, causes, effects, existing controls, and recommended actions. A criticality ranking can prioritize engineering attention, but numerical risk-priority scores should not be treated as precise probabilities unless supported by evidence.

Fault-tree analysis begins with a top event, such as “loss of safe feeder control,” and decomposes it through logical AND and OR relationships. Event-tree analysis starts with an initiating event and follows possible success or failure paths. Both methods help expose single points of failure and inadequate independence.

Maintainability depends on diagnostics, access, tools, training, spare parts, documentation, and safe isolation. Design-for-maintenance principles include modular replacement, standard connectors, local status indication, secure remote diagnostics, event logging, and preservation of settings during component replacement.

6. Documentation and Configuration Management

Documentation is an engineering control, not merely administrative work. Important documents include:

• stakeholder register and requirements specification;
• system architecture and interface control documents;
• electrical schematics, wiring schedules, and network diagrams;
• bills of materials and approved component lists;
• software source code, build instructions, and dependency records;
• firmware versions, device settings, calibration records, and certificates;
• risk assessments, cybersecurity plans, test procedures, and results;
• operating, maintenance, emergency, and decommissioning instructions;
• training records and commissioning handover documents.

Configuration management ensures that the system’s approved identity and contents are known. A configuration item may be a relay setting file, firmware image, gateway, database schema, protection curve, or network rule. Baselines are formally approved versions. Changes require a documented request, impact assessment, authorization, implementation, verification, and rollback plan.

Without configuration control, a failed system may be impossible to reproduce or diagnose because the installed firmware, wiring, and settings differ from the documented design. Version control, checksums, access control, backup, and audit logs are especially important for software and settings that influence electrical safety.

7. Operation, Maintenance, and Lifecycle Data

Maintenance may be corrective, preventive, predictive, or condition-based. Corrective maintenance restores function after failure. Preventive maintenance follows time or usage intervals. Predictive and condition-based maintenance use measurements such as temperature, vibration, insulation condition, battery impedance, breaker operation counts, or abnormal energy patterns.

A maintenance strategy should balance failure consequence, failure likelihood, detectability, inspection cost, and safety. Excessive preventive maintenance can introduce human error and unnecessary outages; insufficient maintenance can increase risk.

Operational data require quality controls. Time synchronization, sensor calibration, missing-data handling, range checks, and event timestamps should be specified. Analytics should distinguish a genuine asset condition from a faulty sensor or communication outage. Artificial intelligence can assist anomaly detection and maintenance prioritization, but it should not silently replace protection logic or accountable engineering judgment. Models require representative training data, performance monitoring, explainability appropriate to the risk, and a safe response to uncertainty.

8. Safety, Cybersecurity, Ethics, and Governance

Safety and cybersecurity are coupled. Unauthorized control of a switch, inverter, charger, or relay can create electrical hazards. Conversely, an overly aggressive security response can interrupt essential services. Security architecture should use least privilege, strong identity management, secure update procedures, network segmentation, encryption where appropriate, logging, vulnerability management, backups, incident response, and recovery testing.

Safety functions should have defined safe states and should not depend unnecessarily on cloud connectivity. Safety-related changes require competent review, controlled testing, and compliance with applicable laws, standards, and utility procedures. Engineers must consult the relevant jurisdictional requirements rather than assuming that a general IoT guideline is sufficient.

Ethical governance includes:

• transparent use of customer and employee data;
• data minimization and retention limits;
• privacy protection for occupancy and energy-use information;
• accessibility for operators with different abilities;
• avoidance of discriminatory or poorly monitored automated decisions;
• clear accountability when an algorithm recommends an action;
• responsible disclosure of vulnerabilities.

9. Sustainability and Decommissioning

Sustainability assessment should include the whole lifecycle rather than only operational energy savings. Relevant impacts include embodied materials, manufacturing, transport, installation, standby energy, communications, battery replacement, software support, repairability, and end-of-life treatment.

A simple lifecycle energy balance can be expressed as:

Here, all terms are energies expressed in a consistent unit over the selected assessment boundary. E_saved is avoided energy use, while the other terms represent lifecycle inputs. This simplified expression does not by itself establish carbon impact because electricity and materials have different emission factors; a carbon assessment should multiply relevant energy and material flows by defensible factors.

Design choices that improve sustainability include long-life and repairable equipment, modular upgrades, open interfaces, low-power communication, recyclable materials, secure software support, local processing that reduces unnecessary data transfer, and avoidance of premature replacement.

Decommissioning must be planned from the beginning. The process may include authorization, safe isolation, data export and retention decisions, credential revocation, secure erasure, removal of batteries and hazardous materials, recycling or reuse, disposal records, and updating asset registers. A device that is physically removed but remains accessible through a cloud account is not fully decommissioned.

10. Illustrative Case: Smart Building Energy and Demand Management

Background

A university plans to install smart meters, temperature sensors, controllable air-handling units, photovoltaic monitoring, and a dashboard in a multi-building campus. The goals are to reduce peak demand, identify inefficient operation, and provide facilities staff with actionable information.

Problem

The existing building-management systems use different protocols. Facilities staff are concerned about nuisance alarms and loss of control during network failures. The information-technology department requires segmentation from the academic network, while occupants are concerned that detailed energy data could reveal schedules and behavior.

Analysis

Stakeholder workshops identify the following critical needs: local control must continue during Internet outages; peak-demand measurements must be time synchronized; alarms must be prioritized; the system must not expose personally identifiable information; and maintenance staff must be able to replace a gateway without rebuilding the system.

The engineering team evaluates a cloud-only architecture, a fully local architecture, and a hybrid architecture. The hybrid option is selected: local controllers maintain schedules and safe operating limits, while an edge gateway buffers data and performs preliminary analytics. A central platform receives aggregated data, supports reporting, and provides fleet-level analysis.

Approach and solution

Requirements are written with measurable acceptance criteria. A digital model estimates thermal response and peak-demand behavior. A laboratory HIL setup tests the gateway and control logic against simulated loads, sensor failures, stale data, and communication loss. Pilot installation occurs in one building before campus-wide deployment.

Verification confirms sensor scaling, timestamp accuracy, alarm behavior, access permissions, fallback control, and recovery after gateway restart. Validation involves facilities operators using the system during realistic work orders. Privacy controls aggregate data and restrict detailed views according to role.

Outcome

The pilot demonstrates that local control remains available during a simulated Internet outage and that nuisance alarms are reduced by priority rules and persistence delays. The project team identifies an unexpected problem: two meters report opposite current polarity because of installation orientation. The commissioning procedure is updated to include a signed polarity check against a calibrated reference.

Learning points

The case illustrates that architecture, testing, human factors, cybersecurity, and maintenance cannot be separated. HIL testing reduces risk, but site commissioning remains necessary. A technically accurate measurement is not useful if its sign convention is wrong or if operators cannot interpret the alarm. Requirements, configuration baselines, and lessons from the pilot provide the foundation for scalable deployment.

11. Challenges and Contemporary Developments

Smart electrical systems face rapid technology change. Communication standards, cloud services, embedded operating systems, and AI tools may become obsolete before the physical equipment reaches the end of its useful life. Open protocols and well-defined interfaces reduce lock-in but do not eliminate compatibility testing.

Other challenges include limited field skills, counterfeit or unsupported devices, uncertain wireless performance, supply-chain vulnerabilities, software dependencies, and the difficulty of testing rare combinations of faults. Digital twins and remote laboratories are increasingly useful, but their credibility depends on model validation and disciplined configuration. Automated test generation and AI-assisted code review can improve productivity, yet generated results require human verification and security review.

Best practice is therefore not to seek a single “perfect” architecture. It is to establish explicit requirements, analyze hazards and failure modes, test credible abnormal conditions, control changes, preserve evidence, and continuously learn from operation.

Chapter Summary

Systems engineering provides an organized method for transforming stakeholder needs into safe, useful, and maintainable smart electrical systems. The lifecycle begins with stakeholder and requirements analysis and continues through architecture selection, modeling, prototyping, integration, verification, validation, commissioning, operation, maintenance, and retirement.

Architecture decisions should consider latency, resilience, cybersecurity, interoperability, lifecycle cost, and obsolescence. Simulation and HIL testing reveal design weaknesses before field deployment, while verification confirms conformance and validation confirms fitness for real use. Reliability models, FMEA, and fault-tree analysis support risk reduction, but their assumptions must be respected. Documentation and configuration management preserve traceability and make controlled change possible. Sustainable design includes energy, materials, repairability, data practices, and responsible decommissioning. Throughout the lifecycle, safety, cybersecurity, privacy, human factors, and professional accountability must be treated as engineering requirements.

Key Terms

Systems engineering: An interdisciplinary method for defining, developing, integrating, operating, and retiring complete systems.

Stakeholder: A person or organization that affects, uses, owns, regulates, maintains, or is affected by a system.

Requirement: A necessary, testable statement of a system function or property.

Traceability: The ability to link needs, requirements, design elements, tests, and evidence.

Architecture: The organized structure of system elements, interfaces, and relationships.

Edge computing: Processing data near the source rather than exclusively in a remote platform.

Hardware-in-the-loop: Testing real hardware against a real-time simulated plant or environment.

Verification: Determining whether specified requirements have been satisfied.

Validation: Determining whether the system meets its intended real-world purpose.

Commissioning: The controlled process of checking and placing an installed system into service.

Reliability: The probability of performing a required function for a specified time and condition.

Availability: The proportion or probability of time that a repairable system is operational.

Maintainability: The ease and speed with which a system can be restored or kept operational.

FMEA: A structured analysis of failure modes, effects, causes, and controls.

Fault-tree analysis: A deductive analysis that decomposes a defined top event into contributing faults.

Configuration management: Controlled identification, documentation, change, and auditing of system versions.

Baseline: An approved configuration against which future changes are assessed.

Lifecycle assessment: Evaluation of impacts from production through use and end of life.

Decommissioning: Safe retirement, data handling, removal, reuse, recycling, or disposal of a system.

Review Questions

Short Answer Questions

1. What is the difference between verification and validation?
2. Why is edge control often preferred for time-critical electrical protection?
3. Name four types of requirements used in smart electrical systems.
4. What purpose does a configuration baseline serve?
5. Why must a reliability model state its assumptions?

Long Answer Questions

1. Explain how stakeholder analysis and requirements traceability reduce lifecycle risk.
2. Compare centralized, edge, and hybrid architectures for a smart microgrid.
3. Describe a complete verification and commissioning strategy for an IoT-enabled substation.
4. Explain how FMEA, fault-tree analysis, and maintainability planning complement one another.
5. Discuss how cybersecurity, privacy, safety, and sustainability should influence system architecture.

Analytical / Application Questions

1. A smart charger must continue safe local operation during loss of cloud connectivity. Propose an architecture, identify key requirements, and define tests that would validate the fallback behavior.
2. Two independent components have reliabilities of 0.96 and 0.95 over the mission period. Calculate the reliability if both are required, and if either can provide the function. State the independence assumption and interpret the results.
3. Design a lifecycle plan for retiring a networked photovoltaic monitoring system. Include electrical safety, credentials, data retention, environmental handling, documentation, and verification of successful decommissioning.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes verification from validation?

A. Verification checks conformance to requirements; validation checks fitness for intended use.

B. Verification occurs only after decommissioning; validation occurs during design.

C. Verification concerns cost; validation concerns wiring diagrams only.

D. Verification is performed by users; validation is performed only by suppliers.

Correct Answer: A. Verification checks conformance to requirements; validation checks fitness for intended use.

Question 2

Which architecture is generally most suitable when local safety-critical control must continue during cloud or Internet failure?

A. Cloud-only architecture

B. Hybrid architecture with local control and remote analytics

C. Centralized architecture with no local controller

D. Manual architecture with no sensors

Correct Answer: B. Hybrid architecture with local control and remote analytics

Question 3

For a constant failure rate λ, which expression represents reliability at time t under the exponential model?

A. R(t) = 1 − e^(−λt)

B. R(t) = e^(−λt)

C. R(t) = λt

D. R(t) = t/λ

Correct Answer: B. R(t) = e^(−λt)

Question 4

Two independent components have reliabilities 0.98 and 0.97, and both are required. What is the system reliability?

A. 0.0494

B. 0.9506

C. 0.9700

D. 0.9994

Correct Answer: B. 0.9506

Question 5

What is the primary purpose of hardware-in-the-loop testing?

A. To replace all field commissioning permanently

B. To test real hardware against a real-time simulated environment

C. To measure only the embodied carbon of hardware

D. To eliminate the need for requirements

Correct Answer: B. To test real hardware against a real-time simulated environment

Question 6

Which activity is an example of validation rather than verification?

A. Checking that firmware matches the approved version

B. Inspecting a wiring diagram against the design

C. Having representative operators use the system in realistic workflows

D. Measuring sensor output against a calibrated reference

Correct Answer: C. Having representative operators use the system in realistic workflows

Question 7

Which document most directly links requirements to test evidence?

A. Requirements traceability matrix

B. Marketing brochure

C. Uncontrolled personal notebook

D. Procurement invoice

Correct Answer: A. Requirements traceability matrix

Question 8

A system has a failure rate λ and repair rate μ under the idealized constant-rate model. Which expression gives steady-state availability?

A. A = λ/(λ + μ)

B. A = μ/(λ + μ)

C. A = λμ

D. A = 1/(λ + μ)

Correct Answer: B. A = μ/(λ + μ)

Question 9

Which action is essential when decommissioning a networked IoT device?

A. Leaving its cloud credentials active for possible future use

B. Removing it physically but retaining unrestricted remote access

C. Revoking credentials and handling stored data according to policy

D. Deleting only the paper purchase order

Correct Answer: C. Revoking credentials and handling stored data according to policy

Question 10

What is a major limitation of a simple series or parallel reliability calculation?

A. It assumes that units and probabilities cannot be defined

B. It automatically includes all common-cause failures

C. It commonly assumes independent component behavior

D. It can be used only for mechanical systems

Correct Answer: C. It commonly assumes independent component behavior