System Architecture and Co-Design

Introduction and Context

A mechatronic product is not obtained by adding a mechanical design to an electronic design and then writing software for it. Its behavior emerges from the interaction of structure, sensing, actuation, computation, communication, energy conversion, and control. Consequently, the architecture of a mechatronic system must be designed deliberately before detailed component selection begins.

System architecture describes how a system is decomposed, how its elements interact, and where responsibilities are located. Co-design extends this idea by requiring mechanical, electrical, control, software, manufacturing, safety, and maintenance decisions to be considered together. A decision made in one domain often changes the requirements of another. For example, reducing mechanical stiffness may lower mass but increase vibration, sensor noise, control effort, and software complexity.

This chapter develops functional, logical, and physical architectures; explains partitioning among engineering domains; compares centralized, distributed, and modular implementations; and presents disciplined design-review methods. The emphasis is on decisions made at the system level, before detailed design makes change expensive.

Learning Objectives

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

1. Distinguish functional, logical, and physical architecture.
2. Convert stakeholder needs into functions, interfaces, and allocations.
3. Partition responsibilities among mechanics, electronics, control, and software.
4. Compare centralized, distributed, and modular architectures using technical criteria.
5. Identify interface risks, coupling, timing constraints, and failure propagation.
6. Use traceability, interface control, and design reviews to manage co-design.
7. Evaluate an architecture through a realistic mechatronic case.

1. Architecture as a Design Model

An architecture is a structured representation of a system and its relationships. It answers four questions:

• What must the system do?
• Which elements perform those functions?
• How do those elements exchange matter, energy, information, and authority?
• Under what constraints must the system operate?

Architecture is not the same as a parts list. A parts list identifies components; an architecture explains responsibilities and relationships. Two products may use identical components but have different architectures because functions, interfaces, and control authority are organized differently.

A useful architecture must be understandable at several levels. Managers need to see system boundaries, risks, and verification responsibilities. Mechanical engineers need loads, envelopes, and mounting interfaces. Electrical engineers need power, signals, grounding, and electromagnetic constraints. Control engineers need plant dynamics, sensors, actuators, sampling, and stability margins. Software engineers need data ownership, timing, states, and fault behavior.

1.1 System boundary and environment

The system boundary defines what is designed and controlled by the project. The environment includes operators, workpieces, external networks, temperature, vibration, utilities, and regulatory conditions. Poor boundary definition causes omissions. For example, treating a battery charger, network switch, or operator interface as external may hide important safety and performance dependencies.

A context diagram should show external actors and flows. Flows may include:

• material: workpieces, fluid, air, or waste;
• energy: electrical, hydraulic, pneumatic, thermal, or mechanical power;
• information: commands, measurements, configuration, and diagnostics;
• constraints: safety rules, standards, environmental limits, and production policies.

1.2 Architecture viewpoints

No single drawing is sufficient. Different viewpoints expose different risks:

These viewpoints should remain consistent. If a logical controller uses a position signal, the physical architecture must identify a sensor and signal path that can supply it. If a safety requirement demands removal of actuator energy, the power architecture must provide a credible means of achieving that state.

2. Functional, Logical, and Physical Architectures

2.1 Functional architecture

The functional architecture expresses what the system must accomplish without prematurely selecting implementation. A top-level function such as “automatically position a tool” can be decomposed into “measure position,” “compute position error,” “generate motion command,” “convert command to actuator effort,” and “transmit force through the mechanism.”

Functions should be stated with an active verb and an object. “Position workpiece” is stronger than “positioning,” because it identifies an intended transformation. Each function should have defined inputs, outputs, conditions, and performance measures.

A functional flow block diagram (FFBD) or functional hierarchy can expose missing transformations. It also supports requirements traceability: each required behavior should map to one or more functions and later to verification evidence.

2.2 Logical architecture

The logical architecture assigns functions to conceptual elements, without necessarily fixing specific commercial components. Examples include a motion-control service, a trajectory generator, a safety monitor, an energy-management unit, and a communications bus.

Logical elements are defined by responsibility and interfaces. A logical element may later be implemented by a microcontroller task, PLC program, FPGA block, embedded computer, or mechanical subsystem. This separation prevents early commitment to a particular technology and makes alternative allocations easier to compare.

2.3 Physical architecture

The physical architecture maps logical elements to real hardware, software, structures, and manufactured assemblies. It identifies processor types, sensors, actuators, cables, connectors, housings, brackets, power supplies, and software deployment units.

Physical architecture must account for nonfunctional properties such as mass, heat dissipation, accessibility, electromagnetic compatibility, serviceability, and manufacturability. A physically elegant arrangement may be logically poor if communication latency prevents stable control. Conversely, a logically clean architecture may be physically impossible because a sensor cannot be mounted with adequate stiffness or line of sight.

Figure: Architecture becomes progressively more implementation-specific from functional to physical views.

2.4 Behavioral and operational architecture

A mechatronic system is also characterized by states and transitions. Typical states include Off, Initialization, Ready, Running, Paused, Fault, and Safe Shutdown. A state model defines which commands are accepted, which outputs are energized, and what conditions permit transition.

For time-critical systems, timing is part of architecture. A control loop with sampling period Tₛ must receive measurements, execute computation, and update the actuator within an appropriate deadline. If the total worst-case delay approaches the dynamic time scale of the plant, performance and stability can deteriorate. Timing requirements should therefore specify not only average cycle time but also deadline, jitter, synchronization, and behavior after missed deadlines.

3. From Requirements to Architecture

Architecture begins with needs but must not remain at the level of vague aspirations. A disciplined flow is:

1. Identify stakeholders and operational scenarios.
2. State measurable system requirements.
3. Define system boundary and external interfaces.
4. Develop functional decomposition.
5. Identify performance, safety, and environmental constraints.
6. Generate alternative logical architectures.
7. Allocate functions and requirements.
8. Map the selected allocation to physical elements.
9. Define interfaces and verification methods.
10. Review the architecture before detailed design.

A requirement should be singular, feasible, verifiable, and traceable. “The axis shall reach a commanded position within ±0.1 mm under the specified load” is more useful than “the axis shall be accurate.” The requirement also requires conditions: speed, temperature, payload, measurement reference, and settling criterion.

3.1 Functional decomposition and allocation

Decomposition should stop when a function can be assigned, estimated, and verified without hiding important interactions. Excessive decomposition creates documentation without insight; insufficient decomposition conceals interfaces and failure modes.

Allocation is the decision that a function will be performed by a particular domain or combination of domains. Allocation criteria include:

• required physical transformation;
• bandwidth and timing;
• precision and noise sensitivity;
• safety integrity and independence;
• energy efficiency;
• cost, mass, and packaging;
• computational resources;
• manufacturability and maintenance;
• cybersecurity and upgradeability.

Allocation is not always exclusive. “Limit force” may involve mechanical compliance, a load cell, a real-time controller, and a software safety limit. The architecture should state which element provides normal regulation and which provides independent protection.

3.2 Interface definition

An interface is a contract between elements. It specifies the exchanged quantity and its allowable conditions. An interface control document commonly includes:

• physical location and connector or mounting geometry;
• power voltage, current, inrush, and grounding;
• signal range, units, accuracy, bandwidth, and update rate;
• communication protocol, addressing, and error handling;
• timing, synchronization, and ownership;
• environmental and electromagnetic limits;
• startup, shutdown, and fault behavior.

For example, “position output” is incomplete. A useful specification might state that the signal is a 0–5 V representation of 0–100 mm, with specified linearity, bandwidth, reference ground, update rate, and behavior on sensor failure.

4. Co-Design Across Engineering Domains

Co-design means optimizing interacting decisions rather than optimizing disciplines independently. A practical co-design team maintains a shared model of requirements, interfaces, assumptions, and verification evidence.

4.1 Mechanics and control

Mechanical stiffness, damping, backlash, friction, mass, and inertia shape the plant dynamics. A lightweight link may reduce actuator power but introduce flexible modes. A controller designed from a rigid-body approximation may then excite structural resonance.

For a simplified rotational plant, torque and angular acceleration are related by:

where J is rotational inertia in kg·m², θ is angular position in radians, τₐ is applied actuator torque in N·m, τₗ is load torque in N·m, and b is viscous damping in N·m·s/rad. The model assumes a single rigid rotational degree of freedom and linear viscous damping. It does not represent backlash, saturation, Coulomb friction, or flexible modes.

A more complete design may require measured frequency-response data, finite-element analysis, or multibody simulation. The control engineer must know whether the mechanical model is valid in the operating range.

4.2 Electronics and mechanics

Electronics influence packaging, thermal behavior, mass distribution, grounding, and vibration tolerance. A motor drive may generate heat requiring a conductive path to a frame or forced cooling. Cable routing may limit joint motion. Sensor mounting must avoid compliance that converts acceleration into measurement error.

Power architecture is particularly important. A nominal actuator voltage is not enough; peak current, regeneration, energy storage, fuse coordination, isolation, and fault interruption must be considered. Grounding and shielding decisions can affect both safety and measurement quality.

4.3 Control and software

Control algorithms operate through software, but software architecture must respect control assumptions. Sampling period, quantization, computation delay, task scheduling, numerical representation, and watchdog behavior influence the implemented controller.

For a discrete proportional-integral controller, one common positional form is:

where u[k] is the control output, e[k] is error at sample k, Kₚ is proportional gain, Kᵢ is integral gain, and Tₛ is sampling period. This form assumes a fixed sample period and requires practical measures such as output saturation handling and anti-windup. It is not a complete controller specification: filtering, derivative action, limits, initialization, and fault response must also be defined.

Software should separate safety-critical functions from convenience functions where independence is required. A visualization task should not be able to delay an emergency stop path. Data ownership must be explicit: one component should normally be authoritative for each command, state, and configuration item.

4.4 Human factors and safety

The architecture must account for operators, maintainers, and bystanders. Controls should communicate state clearly, prevent hazardous ambiguity, and support recovery from foreseeable errors. Safety functions should be independent enough that a single failure does not defeat the protective measure.

A hazard analysis can use a sequence such as hazard identification, initiating-event analysis, risk estimation, protective-function specification, and verification. Applicable standards depend on the sector and jurisdiction; examples may include machinery functional safety, electrical safety, robot safety, and software lifecycle standards. Standards must be identified from current authoritative sources rather than assumed from informal practice.

5. Centralized, Distributed, and Modular Architectures

5.1 Centralized architecture

In a centralized architecture, a principal controller performs most computation and coordinates local inputs and outputs. Advantages include a unified system model, straightforward global coordination, and potentially lower software duplication. Disadvantages include a larger controller, concentrated failure risk, longer wiring, and possible bottlenecks in computation and communication.

Centralization is attractive when axes are tightly coordinated, the physical area is small, and a high-performance controller is readily available. It becomes less attractive when wiring is extensive, subsystems must be independently replaceable, or fault containment is important.

5.2 Distributed architecture

A distributed architecture assigns computation and often control to multiple nodes connected by a network. Local nodes can close fast loops near sensors and actuators, reducing wiring and allowing physical separation. However, network delay, jitter, synchronization, configuration management, cybersecurity, and fault diagnosis become architectural concerns.

Distribution does not automatically mean independence. If every node depends on one network master, the design may still have a central failure point. Communication loss behavior must be specified: hold last command, move to a safe state, complete a controlled stop, or continue under local authority.

5.3 Modular architecture

A modular architecture divides the product into units with well-defined interfaces and bounded responsibilities. Modules may be physical, software, or both. Modularity supports reuse, parallel development, service replacement, and technology upgrades. Its costs include interface overhead, duplicated resources, and the risk that nominally independent modules become tightly coupled through undocumented assumptions.

A module should have high internal cohesion and controlled external coupling. Cohesion means that closely related responsibilities remain together. Coupling measures dependence among modules. Good architecture does not seek zero coupling; it makes necessary coupling explicit, stable, and testable.

The choice should be evidence-based. Useful evaluation criteria include lifecycle cost, timing determinism, fault containment, scalability, diagnostic quality, thermal and packaging constraints, and verification effort.

6. Architecture Evaluation and Design Reviews

A design review is a decision-making activity, not a presentation ceremony. It should test whether the architecture is sufficiently mature for the next development stage.

6.1 Review evidence

A credible architecture review should include:

• approved needs and measurable requirements;
• context, functional, logical, and physical views;
• interface control information;
• operating modes and state transitions;
• preliminary hazard and failure analyses;
• timing, power, thermal, and mass budgets;
• alternatives considered and decision rationale;
• verification and validation strategy;
• open issues, assumptions, owners, and due dates.

6.2 Traceability

A traceability matrix links needs to requirements, functions, allocated elements, interfaces, risks, and verification methods. Traceability is not merely administrative. It reveals orphan requirements with no implementation, functions with no requirement, and verification tests that do not address the intended claim.

A requirement should have a verification method such as inspection, analysis, demonstration, or test. For example, connector identification may be inspected; thermal margin may be analyzed and tested; emergency stopping may require a witnessed test under defined conditions.

6.3 Quantitative budgets

Budgets expose whether the architecture closes. Examples include power, mass, heat, processor utilization, network bandwidth, timing, and positional error. For independent contributors to a worst-case additive error budget:

where Eᵢ is the signed contribution of error source i and E_total is the conservative worst-case bound. The absolute values assume all contributors can align unfavorably. If contributors are statistically independent and random, a root-sum-square estimate may be appropriate:

The root-sum-square expression assumes zero-mean, independent random contributions and should not be used for known systematic errors or correlated effects. Both estimates must use the same units.

6.4 Review process

A disciplined review proceeds through preparation, independent pre-review, structured discussion, decision recording, and follow-up. Reviewers should ask:

• What assumption, if false, would most damage the design?
• Which interface has the greatest uncertainty?
• What happens after power loss, communication loss, sensor disagreement, or software restart?
• Can the safety claim be verified independently?
• Is the proposed architecture still valid under manufacturing variation and maintenance conditions?

Review findings should be classified, assigned, dated, and closed with evidence. A review is incomplete when disagreement is hidden rather than resolved.

7. Worked Example: Architecture of a Precision Pick-and-Place Axis

The following is an illustrative case, not a report of a specific commercial product.

Background and problem

A laboratory pick-and-place axis must move a 2 kg payload over a 400 mm stroke, place parts within ±0.10 mm, and operate at up to 20 cycles per minute. The system must stop safely when a guard is opened and must remain maintainable by technicians.

Functional analysis

The principal functions are to support the payload, generate linear motion, measure position, regulate motion, detect unsafe conditions, communicate status, and provide operator commands. Important constraints include limited enclosure volume, repeatable calibration, heat dissipation, and protection against unexpected restart.

Alternatives

Three alternatives are considered:

• A centralized industrial controller with remote I/O.
• A distributed servo node at the axis, connected to a supervisory controller.
• A mechanically integrated smart actuator containing motor, drive, encoder interface, and local controller.

The centralized design simplifies coordination and diagnostics but requires longer motor and sensor wiring. The smart actuator reduces cabling but creates a less accessible thermal and service package. The distributed servo node provides local loop closure while retaining supervisory coordination.

Allocation and analysis

The selected architecture uses a mechanical linear stage, brushless motor, encoder, local servo drive, supervisory controller, safety relay or safety-rated controller, and operator interface. The fast current and velocity loops are local to the drive. The supervisory controller performs trajectory generation, position commands, sequencing, diagnostics, and production communication. The safety system independently monitors the guard and removes or controls hazardous actuator energy according to the applicable safety design.

Assume the position-error budget contains the following worst-case contributions: encoder scale error 0.025 mm, mechanical backlash 0.030 mm, thermal expansion 0.020 mm, structural deflection 0.015 mm, and calibration residual 0.010 mm. The conservative total is:

This exactly consumes the stated tolerance and leaves no margin for unmodeled effects. The architecture should therefore be revised or characterized further. If the values were independent random standard deviations rather than worst-case limits, the root-sum-square value would be approximately 0.049 mm, but that result cannot justify a worst-case ±0.10 mm claim without a suitable statistical validation plan.

Outcome and design decision

The distributed architecture is selected because local loop closure reduces timing sensitivity and keeps encoder wiring short, while the supervisory controller preserves coordinated sequencing. The design includes a network-loss policy, independent safety monitoring, accessible drive replacement, shield termination rules, and a calibration procedure. The error-budget review triggers a stiffer carriage and improved calibration rather than accepting zero margin.

Learning points

The case demonstrates that architecture is a negotiation among performance, safety, serviceability, and implementation risk. It also shows why a design review must examine margins, not merely nominal compliance. A system that meets a requirement only at the sum of estimated ideal contributions is not yet robust.

8. Contemporary Developments and Responsible Use of AI

Current mechatronic systems increasingly use edge computing, digital twins, model-based systems engineering, time-sensitive networking, and data-driven diagnostics. These technologies can improve observability and predictive maintenance, but they do not remove the need for physical models, requirements, and verification.

AI may assist with anomaly detection, parameter estimation, documentation search, code review, and design-space exploration. However, generated designs or code must be treated as proposals requiring engineering validation. Risks include training-data bias, undocumented assumptions, cybersecurity vulnerabilities, opaque decisions, and unsafe behavior outside the training distribution. Safety-critical control should retain deterministic, testable behavior and clearly defined fallback modes unless a suitable assurance argument supports another approach.

Digital twins are useful only when model fidelity, parameter provenance, uncertainty, and update procedures are documented. A visually convincing simulation is not evidence that a physical system is safe or accurate.

9. Best-Practice Checklist

Before approving a system architecture, confirm that:

1. The system boundary and external actors are explicit.
2. Functions are stated independently of premature component choices.
3. Requirements are measurable, feasible, and traceable.
4. Logical responsibilities and physical implementations are consistent.
5. Every important interface has an owner and defined behavior.
6. Timing, power, thermal, mass, and error budgets include margin.
7. Normal, degraded, fault, maintenance, and restart modes are defined.
8. Safety functions are not dependent on unverified convenience software.
9. Network loss, sensor disagreement, and power interruption have specified responses.
10. Alternatives and rejected options are recorded with rationale.
11. Verification methods are planned before detailed implementation.
12. Assumptions, uncertainties, and review actions have owners and closure evidence.

Chapter Summary

System architecture organizes the functions, responsibilities, interfaces, and physical elements of a mechatronic product. Functional architecture states what the system must do; logical architecture assigns responsibilities to conceptual elements; and physical architecture identifies the actual hardware, software, and structures. Behavioral, operational, safety, and verification viewpoints complete the description.

Co-design is required because mechanical dynamics, electronics, control, software timing, safety, manufacturing, and maintenance are coupled. Function allocation should consider performance, timing, energy, safety, cost, packaging, and lifecycle issues. Centralized architectures simplify global coordination, distributed architectures support local autonomy and reduced wiring, and modular architectures improve reuse and serviceability; each introduces corresponding risks.

Effective design reviews use traceability, interface contracts, operating modes, failure analysis, quantitative budgets, alternatives, and verification evidence. The central professional principle is to make assumptions and couplings visible early, when they can still be changed economically.

Key Terms

Architecture: Structured description of system elements, responsibilities, and relationships.

System boundary: Definition of what is included in the system and what belongs to its environment.

Functional architecture: Description of required transformations without committing to implementation.

Logical architecture: Allocation of responsibilities to conceptual elements and services.

Physical architecture: Mapping of logical elements to real hardware, software, and structures.

Interface: Defined contract for exchanging matter, energy, information, or authority.

Function allocation: Assignment of a function to a domain, element, or combination of elements.

Co-design: Concurrent design of interacting disciplines and their interfaces.

Centralized architecture: Architecture in which a principal controller performs most coordination or computation.

Distributed architecture: Architecture in which multiple connected nodes perform local computation or control.

Modular architecture: Architecture composed of units with bounded responsibilities and defined interfaces.

Coupling: Dependence of one element on another.

Cohesion: Degree to which responsibilities within an element belong together.

Traceability: Ability to follow relationships among needs, requirements, design elements, risks, and verification.

Interface control document: Controlled specification of an interface’s physical, electrical, logical, and behavioral properties.

Design review: Structured evaluation of design maturity, risks, decisions, and evidence.

Error budget: Allocation and combination of permitted contributions to a performance error.

Fail-safe state: State intended to reduce hazard when a fault or abnormal condition occurs.

Digital twin: A maintained computational representation linked to a physical system and its data.

Review Questions

Short Answer Questions

1. What is the difference between functional and physical architecture?
2. Why must an interface specify behavior during startup and fault conditions?
3. State two advantages and two risks of a distributed architecture.
4. What is the purpose of a traceability matrix?
5. Why should a design review examine margins rather than nominal performance only?

Long Answer Questions

1. Explain how a motion-control function can be decomposed and allocated across mechanics, electronics, control, and software.
2. Compare centralized, distributed, and modular architectures for a multi-axis machine.
3. Describe a disciplined process for converting stakeholder needs into an approved physical architecture.
4. Explain how mechanical stiffness, sensor placement, sampling, and software scheduling interact in a closed-loop system.
5. Discuss the role of safety, maintainability, and cybersecurity in system architecture decisions.

Analytical / Application Questions

1. A system has a centralized controller but physically separated axes with long sensor cables. Recommend whether the architecture should remain centralized or become distributed. State the evidence and trade-offs you would analyze.
2. An axis has worst-case error contributions of 0.040 mm, 0.025 mm, 0.015 mm, and 0.010 mm against a ±0.10 mm requirement. Calculate the conservative total and determine whether margin remains. Explain what additional information is needed before using an RSS estimate.
3. A networked actuator continues its last command when communication is lost. Analyze the safety and control risks and propose a more appropriate degraded-mode policy.

Multiple Choice Questions with Answers

Question 1

Which architecture view describes required transformations without selecting specific hardware?

A. Functional architecture

B. Physical architecture

C. Procurement architecture

D. Maintenance architecture

Correct Answer: A. Functional architecture

Question 2

Which item is most appropriately specified in an interface control document?

A. A vague statement that a sensor is accurate

B. Signal range, units, update rate, and fault behavior

C. Only the supplier’s company name

D. The project meeting schedule

Correct Answer: B. Signal range, units, update rate, and fault behavior

Question 3

A distributed architecture most directly creates which additional design concern?

A. Elimination of all timing issues

B. Network delay, jitter, and synchronization

C. Removal of the need for fault handling

D. Guaranteed lower total cost

Correct Answer: B. Network delay, jitter, and synchronization

Question 4

For worst-case error contributions of 0.02 mm, 0.03 mm, and 0.01 mm, what is the conservative total?

A. 0.01 mm

B. 0.02 mm

C. 0.04 mm

D. 0.06 mm

Correct Answer: C. 0.04 mm

Question 5

Which statement best describes co-design?

A. Completing mechanical design before any electronics work

B. Designing each discipline independently and integrating at the end

C. Considering interacting disciplinary decisions concurrently

D. Replacing requirements with simulation results

Correct Answer: C. Considering interacting disciplinary decisions concurrently

Question 6

What is the main purpose of a state model in a mechatronic system?

A. To list purchased components

B. To define modes, transitions, commands, and output behavior

C. To calculate material density

D. To replace all safety analysis

Correct Answer: B. To define modes, transitions, commands, and output behavior

Question 7

If an element has high cohesion, its responsibilities are generally:

A. Unrelated and widely scattered

B. Closely related and internally consistent

C. Assigned randomly to external modules

D. Undefined until testing

Correct Answer: B. Closely related and internally consistent

Question 8

Which condition is required before using a root-sum-square error estimate responsibly?

A. All errors are known systematic biases

B. Contributions are suitably independent random quantities

C. Units are deliberately different

D. The requirement has no tolerance

Correct Answer: B. Contributions are suitably independent random quantities

Question 9

Why is an independent safety path often used?

A. To make normal software more decorative

B. To reduce the chance that one ordinary failure defeats protection

C. To eliminate the need for sensors

D. To increase undocumented coupling

Correct Answer: B. To reduce the chance that one ordinary failure defeats protection

Question 10

A design review is most effective when it produces:

A. Only a polished presentation

B. Unassigned opinions without deadlines

C. Recorded decisions, risks, owners, and closure evidence

D. A parts list without interfaces

Correct Answer: C. Recorded decisions, risks, owners, and closure evidence