CPS Architectures, Interoperability and Integration

Introduction and Context

A cyber-physical system (CPS) combines computation, communication, sensing, actuation, and physical processes into a coordinated system. Examples include autonomous mobile robots, smart manufacturing cells, connected vehicles, medical devices, and intelligent energy networks. In each case, software does not merely process information: it influences physical behaviour, while physical events continuously affect computation.

The architecture of a CPS is the organized structure of its components, relationships, interfaces, data flows, control flows, and operational responsibilities. Architecture is therefore more than a block diagram. It determines how a system can be expanded, tested, secured, maintained, and integrated with other systems.

CPS architecture is difficult because the system must satisfy several forms of correctness simultaneously. A controller may be mathematically stable but useless if sensor data arrive too late. Two devices may be connected but unable to interpret one another’s data. A system may be functionally effective but unsafe because a failure in an information network disables a protective actuator. Good CPS design addresses computation, communication, physical dynamics, timing, safety, security, and organizational context together.

This chapter develops layered, component-based, service-oriented, and distributed CPS architectures. It explains interfaces, middleware, interoperability, reference models, standards, systems-of-systems principles, and integration practices relevant to mechatronics engineers.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain why architectural abstraction is necessary in cyber-physical systems.
2. Compare layered, component-based, service-oriented, and distributed architectures.
3. Design suitable interfaces and distinguish syntactic, semantic, and pragmatic interoperability.
4. Explain the role of middleware, gateways, digital twins, and data models.
5. Apply reference models and standards appropriately without confusing them with complete designs.
6. Analyse timing, dependability, safety, cybersecurity, and integration trade-offs.
7. Apply systems-of-systems principles to a practical industrial CPS.

1. Architectural Foundations

1.1 From components to architectures

A CPS contains physical components such as motors, valves, structures, tools, and material flows; cyber components such as processors, databases, algorithms, and human–machine interfaces; and communication components such as fieldbuses, industrial Ethernet, wireless links, and cloud connections.

A component is a unit with defined responsibilities and interfaces. An architecture specifies how components are arranged and how they interact. The distinction matters because the same components can produce very different systems when connected through different control structures. For example, a robot arm may use a centralized controller, a distributed servo architecture, or a cloud-assisted supervisory system. Each arrangement has different latency, reliability, diagnostic, and security properties.

An architectural description normally includes:

• Structure: components, subsystems, and their relationships.
• Behaviour: events, states, control actions, and data transformations.
• Interfaces: the information and services exchanged between elements.
• Constraints: timing, safety, resource, regulatory, and environmental requirements.
• Deployment: the mapping of software and functions onto physical computing nodes.
• Lifecycle concerns: commissioning, updates, maintenance, retirement, and disposal.

1.2 Functional, logical, and physical views

A useful CPS architecture separates three related views. The functional view identifies what the system must do, such as measure temperature, regulate speed, detect an obstruction, or schedule production. The logical view groups functions into communicating software or control components. The physical view maps those components onto sensors, embedded controllers, industrial PCs, networks, cloud services, and human interfaces.

The views must remain consistent. A function that requires a response within 5 ms cannot be deployed on a remote service whose communication and processing delay is unpredictable. Similarly, a safety function cannot depend solely on a non-safety-certified visualization server.

1.3 Architectural quality attributes

Architecture is evaluated using quality attributes rather than functionality alone.

These attributes can conflict. Encryption may add processing delay; redundancy may increase cost; abstraction may improve portability while hiding timing behaviour; and cloud centralization may simplify management while creating dependence on a wide-area network. Architectural decisions should therefore be linked to measurable requirements.

2. Layered and Reference Architectures

2.1 The purpose of layers

Layering divides a complex system into levels with relatively clear responsibilities. A layer uses services from lower layers and provides services to higher layers. The aim is not to create rigid isolation, but to control complexity and reduce unnecessary coupling.

A practical CPS layering scheme is:

1. Physical process layer: machines, materials, energy flows, and environmental conditions.
2. Sensing and actuation layer: sensors, actuators, signal conditioning, and local I/O.
3. Embedded control layer: real-time control algorithms, safety logic, and device coordination.
4. Communication and middleware layer: messaging, discovery, time synchronization, data conversion, and quality-of-service mechanisms.
5. Supervisory and application layer: production control, optimization, visualization, diagnostics, and enterprise integration.
6. Governance and lifecycle layer: identity, configuration, cybersecurity, safety management, maintenance, and compliance.

These layers are conceptual. A programmable logic controller may contain sensing, control, communication, and diagnostic functions in one enclosure. The architecture still benefits from distinguishing their responsibilities.

Figure: A conceptual layered architecture for a cyber-physical system.

2.2 Benefits and limitations of layering

Layering supports substitution, testing, documentation, and education. A communication protocol can sometimes be replaced without changing the control algorithm. A supervisory application can use standardized data services instead of knowing the electrical details of every sensor.

However, strict layering can be inappropriate for CPS. Timing, energy consumption, safety, and physical dynamics cross layer boundaries. A controller must know whether a measurement is fresh; a middleware service may need to preserve priority; and a safety engineer must understand both software and actuator failure modes. Good architectures therefore permit carefully documented cross-layer contracts, especially for timing and safety.

2.3 Reference models

A reference model is an abstract description of concepts, relationships, and viewpoints common to a class of systems. It is not a product design or an implementation recipe. Reference models help different organizations use consistent terminology and identify missing concerns.

Examples relevant to CPS include the ISO/IEC/IEEE 42010 approach to architecture description, the NIST CPS framework, the RAMI 4.0 model for industrial systems, and the Industrial Internet Reference Architecture. These frameworks differ in emphasis, but commonly address assets, communication, information, functions, users, and lifecycle concerns.

A reference model should be used critically. An engineer first identifies requirements and constraints, then selects useful viewpoints from the model. Copying a reference architecture without considering plant hazards, legacy equipment, timing, or regulatory requirements can produce an attractive but unsuitable design.

3. Component-Based Architecture

3.1 Components, contracts, and composition

Component-based design decomposes a system into units that can be developed, tested, deployed, and replaced with limited impact on other units. A component contract specifies:

• provided services;
• required services;
• input and output data types;
• units, ranges, and quality information;
• timing and execution assumptions;
• fault and recovery behaviour;
• security and authorization requirements.

For example, a motor-speed component may provide a measured-speed signal and require encoder pulses, a valid configuration, and a time-synchronized clock. Its contract should state whether speed is in revolutions per minute or radians per second, the sampling interval, allowable measurement error, and behaviour when the encoder fails.

3.2 Interfaces

An interface is a defined boundary through which components exchange information or invoke functionality. Important interface categories include:

• Data interfaces: messages, variables, streams, and records.
• Service interfaces: operations such as start, stop, calibrate, or obtain status.
• Event interfaces: notifications generated when a condition occurs.
• Physical interfaces: electrical, mechanical, hydraulic, or optical connections.
• Human interfaces: displays, alarms, controls, and procedures.

An interface should specify more than a name. It should define syntax, semantics, timing, units, validity, ownership, security, and error handling. An interface that transmits a value called “temperature” without identifying its sensor location, unit, calibration status, and timestamp is not an adequate engineering contract.

3.3 Component granularity

Very small components may be reusable but create excessive communication and configuration overhead. Very large components may be efficient but difficult to test or replace. A practical boundary usually corresponds to a coherent responsibility, a stable contract, and an independently meaningful test or deployment unit.

In real-time control, partitioning must also consider execution timing and shared resources. Components that exchange high-rate signals may need to execute on the same controller or on a deterministic network. Components requiring independence for safety may need physical or logical separation even when their data rate is low.

4. Interoperability and Middleware

4.1 Three dimensions of interoperability

Interoperability is the ability of independently developed systems to exchange information and achieve intended results. It has at least three dimensions:

1. Syntactic interoperability: systems agree on message structure, encoding, and transport.
2. Semantic interoperability: systems assign the same meaning to exchanged information.
3. Pragmatic or operational interoperability: systems use the information consistently within their processes, policies, and goals.

A JSON message may provide syntactic interoperability while failing semantically if one system interprets “pressure” as absolute pressure and another as gauge pressure. Operational interoperability also requires agreement about authority: whether a command is advisory, mandatory, queued, or immediately executed.

4.2 Middleware functions

Middleware is software between applications and communication mechanisms. In CPS it may provide:

• message transport and routing;
• publish–subscribe or request–response communication;
• service discovery and naming;
• serialization and data conversion;
• buffering and queuing;
• quality-of-service policies;
• time synchronization;
• device management;
• access control and authentication;
• logging, monitoring, and fault reporting.

Middleware reduces application dependence on particular networks or operating systems. Examples of relevant technologies include OPC UA for industrial information exchange, DDS for data-centric real-time communication, MQTT for lightweight publish–subscribe messaging, and industrial protocols such as Modbus, CAN, PROFINET, EtherNet/IP, and EtherCAT. These technologies have different timing, information-model, security, and deployment characteristics; none is universally best.

4.3 Communication patterns

In request–response, a client asks for an operation and receives a reply. It is appropriate for configuration, diagnostics, and transactions. In publish–subscribe, producers publish data and consumers subscribe without a direct point-to-point dependency. It is useful for telemetry and event distribution, but requires careful management of ownership, stale data, and access control. In streaming, a continuous sequence of samples is transferred, often with explicit rate and buffering requirements.

A control loop should not automatically be moved to publish–subscribe middleware merely because the pattern is flexible. The engineer must verify worst-case latency, jitter, packet loss, queue behaviour, and fail-safe action.

4.4 Time and latency budgets

For a closed-loop application, the relevant delay includes sensing, computation, communication, actuation, and physical response. A simple end-to-end budget can be represented as:

Here, each term is a non-negative time interval, measured in seconds or milliseconds. The expression is a planning model; it assumes the stages occur sequentially and that additional scheduling or queueing delays have either been included in the terms or explicitly added. A design is acceptable only if the worst-case or appropriately bounded value satisfies the control and safety requirement, not merely the average value.

For periodic sampling with sampling period T_s, a nominal sampling frequency is:

where f_s is in hertz when T_s is in seconds. This relationship describes the schedule, not the quality of control. Excessive jitter, missed deadlines, sensor noise, and actuator delay may still make the loop unsuitable.

5. Service-Oriented and Distributed CPS Architectures

5.1 Service orientation

A service is a capability offered through a defined interface. Service-oriented architecture emphasizes loose coupling, discoverability, composability, and independent lifecycle management. In CPS, services may include “read vibration,” “set conveyor speed,” “reserve robot,” “diagnose drive,” or “calculate maintenance indicator.”

Service orientation is valuable when equipment from different vendors must cooperate. It also supports gradual modernization: a legacy machine can be wrapped by an adapter that exposes selected functions through a modern service interface.

Loose coupling does not mean absence of constraints. A service contract must specify response time, state transitions, authorization, idempotence, units, data quality, and failure behaviour. A “stop” service, for instance, must state whether it means controlled deceleration, immediate torque removal, or a request that may be rejected when unsafe.

5.2 Distributed architectures

A distributed CPS places computation across several nodes. Distribution may be driven by:

• real-time response near the physical process;
• safety isolation;
• bandwidth reduction;
• resilience and local operation during disconnection;
• privacy or data sovereignty;
• scalability;
• physical geography.

Typical deployments combine edge, fog, and cloud resources. Edge controllers execute fast control and safety functions. Site or fog servers aggregate data and perform coordination or analytics. Cloud platforms support fleet-level analysis, model training, long-term storage, and enterprise integration.

A useful rule is that a function should be placed where its timing, safety, availability, data, and computational requirements can be satisfied. Cloud computing is generally unsuitable as the sole location for a hard real-time emergency shutdown function because wide-area communication and remote service availability are not sufficiently predictable.

5.3 Distribution trade-offs

Distribution introduces partial failure: one node may fail while others continue. It also introduces clock differences, network partitions, duplicated data, inconsistent state, and more complex diagnosis. Engineers must define authoritative sources, synchronization rules, retry policies, and safe degraded modes.

Redundancy can improve availability, but redundant controllers must not issue conflicting commands. Consensus or arbitration may be necessary in supervisory systems, while safety systems often use certified architectures with independent monitoring and defined fail-safe outputs.

6. Integration, Data Models, and Digital Twins

6.1 Integration strategies

Integration can be performed at several levels:

• Point-to-point integration: direct connection between two systems; simple initially but difficult to scale.
• Gateway integration: a gateway translates protocols or data models; useful for legacy equipment but creates a critical dependency.
• Enterprise service bus: centralized integration and routing; supports governance but may become a bottleneck.
• Data-centric integration: systems share a common information model and publish data according to defined semantics.
• API-based integration: documented software interfaces enable controlled access to services and data.

The choice depends on system size, timing, legacy constraints, security, and lifecycle expectations. Point-to-point connections are often acceptable for a small machine but become expensive and fragile as the number of systems increases.

6.2 Information models and semantic integration

A data model defines entities, attributes, relationships, units, identifiers, and constraints. An information model goes further by representing meaning, context, and relationships. For example, an information model may identify a motor, its manufacturer, its location, its rated power, its current operating mode, its maintenance history, and its relationship to a conveyor.

Semantic integration requires common vocabularies, ontologies, asset identifiers, unit conventions, timestamps, and data-quality indicators. Standards such as OPC UA information models, AutomationML, Asset Administration Shell concepts, and Web of Things approaches can support this work, but implementation profiles and organizational agreements remain necessary.

6.3 Digital twins

A digital twin is a maintained digital representation of a physical asset, process, or system, connected to the physical counterpart through data and lifecycle relationships. A simple visualization is not automatically a digital twin. A useful twin normally includes identity, structure, state, history, models, and defined update or synchronization rules.

Digital twins support commissioning, condition monitoring, simulation, operator training, predictive maintenance, and what-if analysis. Their limitations include model uncertainty, stale data, cybersecurity exposure, proprietary formats, and the cost of maintaining correspondence between physical and digital assets. A twin should indicate confidence and data age rather than presenting all calculated values as facts.

7. Systems of Systems

A system of systems (SoS) is an arrangement of independently managed systems that cooperate to provide capabilities not available from the systems individually. Characteristics often include operational independence, managerial independence, evolutionary development, geographic distribution, and emergent behaviour.

A smart factory illustrates the idea. Robots, conveyors, inspection stations, warehouse systems, energy management, and enterprise planning may each have separate owners and lifecycles. Their interaction can produce emergent outcomes such as improved throughput, unexpected congestion, or unsafe resource contention.

SoS engineering emphasizes capability objectives, mission threads, interfaces, governance, and emergent behaviour. It differs from ordinary subsystem integration because the constituent systems may not be redesigned under one authority. Effective practices include:

• defining shared mission and performance measures;
• assigning ownership and authority for each interface;
• specifying assumptions and guarantees;
• testing cross-system scenarios;
• managing configuration and version compatibility;
• planning for graceful degradation;
• establishing joint incident response and change control.

8. A Systematic Architecture and Integration Method

A practical workflow is as follows.

Step 1: Establish the mission and boundaries. Identify the physical process, stakeholders, external systems, operating modes, and assumptions.

Step 2: Capture requirements. Include functional, timing, safety, cybersecurity, availability, environmental, regulatory, and maintenance requirements. Requirements should be testable.

Step 3: Identify hazards and threats. Use hazard analysis, failure analysis, and threat modelling. Consider unsafe commands, stale data, loss of communication, compromised devices, and maintenance errors.

Step 4: Select architectural views. Develop functional, information, communication, deployment, safety, security, and lifecycle views. Use a reference model to organize—not replace—engineering decisions.

Step 5: Define component contracts. Specify interfaces, data types, units, timing, authority, state machines, error handling, and security.

Step 6: Allocate functions. Place functions at sensor, controller, edge, site, or cloud level according to timing, safety, availability, bandwidth, and privacy.

Step 7: Select protocols and standards. Choose based on requirements and interoperability profiles, not popularity alone. Plan gateways for legacy systems and avoid unnecessary protocol proliferation.

Step 8: Verify integration early. Use simulation, hardware-in-the-loop, interface tests, fault injection, timing measurements, and cybersecurity testing.

Step 9: Commission and monitor. Validate identities, calibration, time synchronization, configuration, alarms, logs, and safe states.

Step 10: Manage evolution. Control versions, certificates, data schemas, firmware, models, and dependencies throughout the lifecycle.

9. Illustrative Case: Interoperable Packaging Cell

Background

The following is a fictional but technically realistic illustrative case. A packaging cell contains a robot, conveyor, vision inspection unit, programmable logic controller (PLC), variable-speed drive, safety controller, and manufacturing execution system (MES). The robot and vision system come from different vendors. The existing conveyor uses a legacy fieldbus, while the MES uses an industrial Ethernet and web services.

Problem

The cell experiences intermittent stoppages. The MES receives production counts but cannot reliably associate rejected products with inspection images. Maintenance staff also find that the robot’s fault codes are difficult to interpret. Management wants traceability, improved diagnostics, and future integration with an energy-monitoring service without replacing functioning equipment.

Analysis

The main problems are not simply incompatible cables. They include inconsistent product identifiers, unclear ownership of production state, different timestamps, proprietary robot data, and no common description of inspection results. The safety controller must remain independent of the MES and cloud services. The reject actuator requires deterministic local control.

Approach and solution

The engineering team defines a cell information model. Each product receives a unique production identifier at the infeed. The PLC remains authoritative for product position and machine state. The vision system publishes inspection results containing product identifier, result code, confidence, image reference, timestamp, and calibration version. The robot is connected through a vendor adapter that translates selected status and command services into the cell’s common model.

A gateway translates the legacy conveyor protocol to the plant communication environment. It does not expose safety functions as ordinary business services. The local PLC executes the reject decision because the decision must be made within the conveyor’s deterministic timing window. The MES receives production events and links them to inspection metadata rather than controlling the reject actuator.

The architecture uses separate interfaces for safety, real-time control, diagnostics, and enterprise reporting. Time synchronization is applied to controllers and servers. Data-quality flags identify missing images, late messages, and uncertain associations. Access control restricts commands to authorized engineering roles, while read-only monitoring is available to production supervisors.

Outcome

The cell can associate products with inspection outcomes and image references, while local control continues during temporary MES or cloud disconnection. Maintenance personnel receive normalized fault descriptions together with original vendor codes. The gateway reduces replacement cost, although it becomes a managed component requiring redundancy planning and security updates.

Learning points

1. Interoperability requires shared meaning, not only shared transport.
2. Authority for physical actions must be explicit.
3. Real-time and enterprise functions should not be conflated.
4. Legacy integration is feasible when adapters preserve clear contracts.
5. Data quality, timestamps, and identity are essential to traceability.
6. Safety boundaries must remain visible in the architecture.

10. Challenges, Governance, and Contemporary Developments

10.1 Safety and cybersecurity convergence

Safety protects people and equipment from hazardous behaviour; cybersecurity protects systems and information from malicious or unauthorized behaviour. The two domains interact. A cyberattack that changes a speed limit may create a safety hazard, while a safety shutdown may affect availability and security monitoring.

Architectures should apply least privilege, network segmentation, secure boot where appropriate, authenticated updates, credential management, logging, vulnerability response, and defence in depth. Safety-related functions require hazard-based design and applicable standards, such as the IEC 61508 family or sector-specific standards. Industrial cybersecurity programmes commonly draw on IEC 62443 principles. Compliance with a standard does not remove the need for system-specific risk assessment.

10.2 Governance and responsibility

Integrated CPS raise questions of data ownership, privacy, intellectual property, algorithmic accountability, and responsibility for automated decisions. A plant should know who may issue commands, who approves model updates, who investigates anomalous behaviour, and who is responsible when a third-party service fails.

Artificial intelligence can support anomaly detection, predictive maintenance, scheduling, and visual inspection. However, AI components introduce model drift, uncertain explanations, data bias, adversarial inputs, and validation challenges. A safety-critical action should not depend on an opaque model unless its role, boundaries, verification, and fallback behaviour are justified. Human operators need meaningful alarms and procedures, not merely a numerical confidence score.

10.3 Contemporary directions

Current CPS development emphasizes deterministic industrial networking, time-sensitive communication, edge intelligence, digital engineering, open information models, zero-trust security, modular production, and lifecycle digital threads. These developments improve flexibility but also increase integration complexity. Engineers should evaluate claims against measurable requirements, test environments, operational constraints, and long-term support commitments.

Best-Practice Checklist

• Define architecture boundaries and authoritative sources of state.
• Use explicit contracts containing units, timing, validity, and failure behaviour.
• Separate safety, real-time control, diagnostics, and business integration concerns.
• Prefer standard information models and documented profiles over ad hoc mappings.
• Place computation according to timing, availability, privacy, and safety needs.
• Design for loss of communication and degraded operation.
• Synchronize time and retain data provenance.
• Treat gateways, digital twins, and middleware as engineered components.
• Test worst-case timing, faults, cybersecurity, and version compatibility.
• Manage architecture throughout commissioning, operation, maintenance, and retirement.

Chapter Summary

CPS architecture organizes physical assets, computation, communication, control, information, and lifecycle responsibilities into a coherent whole. Layered architectures reduce complexity, while component-based designs promote modularity through explicit contracts. Service-oriented architectures expose capabilities through interfaces, and distributed architectures place functions across devices, edge nodes, site systems, and cloud services according to timing, safety, availability, bandwidth, and privacy requirements.

Interoperability has syntactic, semantic, and operational dimensions. Middleware supports communication, discovery, quality of service, security, and data conversion, but it cannot compensate for undefined meaning or poor authority rules. Reference models guide architectural viewpoints but do not replace requirements analysis. Information models, gateways, and digital twins support integration and lifecycle management when identity, units, timestamps, provenance, and data quality are controlled.

Systems-of-systems engineering is required when independently managed systems cooperate and produce emergent behaviour. Successful integration depends on explicit boundaries, contracts, standards, verification, cybersecurity, safety governance, and planned evolution. The central professional lesson is that a CPS must be designed as an interacting socio-technical and physical system, not as isolated software connected to hardware at the end.

Key Terms

Architecture: Organized structure of components, relationships, interfaces, and constraints.

Cyber-physical system: A system integrating computation, communication, sensing, actuation, and physical processes.

Layered architecture: Architecture that separates responsibilities into conceptual levels.

Component: A unit with defined responsibilities and interfaces.

Interface: A specified boundary for exchanging information or invoking capability.

Contract: An agreement defining data, behaviour, timing, assumptions, and failure handling.

Middleware: Software that provides communication and integration services between applications and networks.

Interoperability: Ability of independent systems to exchange and use information effectively.

Syntactic interoperability: Agreement on message structure and encoding.

Semantic interoperability: Agreement on the meaning of exchanged information.

Service-oriented architecture: Architecture organized around discoverable capabilities exposed through services.

Publish–subscribe: Communication pattern in which producers publish data and consumers subscribe to it.

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

Digital twin: A maintained digital representation connected to a physical asset or process.

Information model: Structured representation of entities, meanings, relationships, and constraints.

Gateway: Component that connects or translates between networks, protocols, or data models.

System of systems: Independent systems cooperating to provide broader capabilities.

Determinism: Predictability of system timing and behaviour.

Degraded mode: Controlled operation with reduced capability after a fault or loss of service.

Quality of service: Communication or execution properties such as reliability, priority, latency, and durability.

Review Questions

Short Answer Questions

1. Why is architecture more than a physical block diagram in a CPS?
2. Distinguish syntactic interoperability from semantic interoperability.
3. State three responsibilities commonly provided by middleware.
4. Why should a hard real-time shutdown function generally remain local to the physical process?
5. What is the purpose of a component contract?

Long Answer Questions

1. Compare layered, component-based, service-oriented, and distributed CPS architectures. Explain when each is useful and identify important limitations.
2. Explain how a reference model can support CPS design without becoming a substitute for requirements engineering.
3. Discuss the role of information models, gateways, and digital twins in integrating legacy and modern industrial systems.
4. Explain the relationship between functional, logical, and physical architectural views, using a robotic manufacturing cell as an example.
5. Discuss how safety, cybersecurity, timing, and maintainability can conflict in CPS architecture and how an engineer should manage these conflicts.

Analytical / Application Questions

1. Design a high-level architecture for an autonomous warehouse vehicle. Allocate functions among vehicle controllers, an edge server, and a cloud platform, and justify each allocation using timing, safety, availability, and data considerations.
2. A factory has six machines from four vendors, each using different data formats and clocks. Propose an integration strategy that addresses identity, timestamps, semantics, legacy protocols, cybersecurity, and future expansion.
3. A remote analytics service intermittently becomes unavailable. Analyse which functions of a packaging line should continue locally, which may be degraded, and which should stop. Explain how your decision follows systems-of-systems and fail-safe principles.

Multiple Choice Questions with Answers

Question 1

Which dimension of interoperability concerns agreement about the meaning of a data item such as pressure or temperature?

A. Physical interoperability

B. Syntactic interoperability

C. Semantic interoperability

D. Temporal isolation

Correct Answer: C. Semantic interoperability

Question 2

Which function is most appropriately kept local to a machine when it has a hard real-time and safety requirement?

A. Long-term production reporting

B. Emergency protective shutdown

C. Fleet-wide trend visualization

D. Monthly energy analysis

Correct Answer: B. Emergency protective shutdown

Question 3

What is the primary purpose of middleware in a CPS?

A. To replace all physical sensors

B. To provide communication and integration services between applications and networks

C. To eliminate the need for safety analysis

D. To guarantee that every system uses the same hardware

Correct Answer: B. To provide communication and integration services between applications and networks

Question 4

If a sampling period is T_s = 0.01 s, what is the nominal sampling frequency?

A. 0.01 Hz

B. 0.1 Hz

C. 10 Hz

D. 100 Hz

Correct Answer: D. 100 Hz

Question 5

Which statement best describes a digital twin?

A. A static drawing of a machine

B. A maintained digital representation connected to a physical asset or process

C. A replacement for every physical sensor

D. A network cable used for redundant communication

Correct Answer: B. A maintained digital representation connected to a physical asset or process

Question 6

Which communication pattern allows producers to publish data without addressing each consumer directly?

A. Publish–subscribe

B. Point-to-point mechanical coupling

C. Single-user polling only

D. Manual batch transfer

Correct Answer: A. Publish–subscribe

Question 7

Why can strict architectural layering be problematic in CPS?

A. Physical systems never interact with software

B. Timing, safety, and physical dynamics cross layer boundaries

C. Layers prevent any form of documentation

D. Layering requires all components to be from one vendor

Correct Answer: B. Timing, safety, and physical dynamics cross layer boundaries

Question 8

Which item should be included in a robust component contract?

A. Only the component’s brand name

B. Only its source-code length

C. Units, timing assumptions, and failure behaviour

D. The colour of its enclosure

Correct Answer: C. Units, timing assumptions, and failure behaviour

Question 9

What is a defining characteristic of a system of systems?

A. All components must have one owner and one lifecycle

B. Independent systems cooperate to provide broader capabilities

C. It cannot contain physical equipment

D. It must use a cloud-only architecture

Correct Answer: B. Independent systems cooperate to provide broader capabilities

Question 10

In a distributed CPS, what is a major risk introduced by placing functions across multiple nodes?

A. Partial failures and inconsistent state

B. Automatic elimination of network delay

C. Guaranteed semantic interoperability

D. Removal of all cybersecurity requirements

Correct Answer: A. Partial failures and inconsistent state