Technical Competency 1.7: Engineering Systems, Subsystems, & Components

Engineering practice is carried out within systems, where performance is determined not by individual components in isolation but by how multiple elements are structured and interact. These elements, including physical assets, processes, and human inputs, operate within defined limits and continuously influence one another. Sound engineering judgment depends on understanding these relationships, and not just the parts themselves. Competency 1.7 requires engineers to develop a clear and disciplined understanding of how systems are organized, how they behave, and how their performance is managed.

Description of Technical Competency 1.7

Technical Competency 1.7 requires an engineer to demonstrate a clear and structured understanding of systems and their components, with an emphasis on interaction, behavior, and process management. The competency, as outlined in the Competency-Based Assessment (CBA) guidelines published by most Canadian professional engineering regulators using the 34-competency framework, is as follows:

“You understand systems and components of systems.”

The regulators that use the 22-competency framework, such as APEGA, Engineers Yukon, and NAPEG, define this competency as follows:

“…understanding of technical systems and their components and of interactions and constraints in the behaviour of the system. Demonstrate your ability to manage processes within the overall system by monitoring or modifying processes to achieve desired outcomes.”

At its core, this competency is defined through three interconnected expectations as indicated in Figure 1.

First, the engineer must understand each element of an engineering system. This means going beyond surface-level familiarity and being able to interpret how individual components function, what inputs they require, what outputs they produce, and how they behave under different conditions. No element within the system should be treated as a black box without understanding its role.

Second, the engineer must demonstrate a holistic understanding of system behavior. This involves recognizing that system performance is not simply the sum of its parts. Instead, it emerges from the interactions between components, subsystems, and external influences. These interactions may amplify performance, introduce inefficiencies, or create vulnerabilities. Understanding these relationships is essential for predicting system behavior.

Third, the engineer must be capable of managing processes within a system. This includes monitoring system performance, identifying deviations, and modifying processes to achieve optimal outcomes. It reflects an active role in influencing system behavior rather than passively observing it.

Figure 1: An Illustration of an Engineering System, Components and their processes

What Defines an Engineering System?

A system in engineering is not defined only by what it contains, but also by the boundary within which it is being analyzed. That boundary is determined by context, purpose, and the specific problem an engineer is trying to solve. It establishes what is included within the scope of analysis, what is treated as an external influence, and how interactions are interpreted. By setting this boundary, the engineer defines the level of detail, the interfaces to be considered, and the assumptions that that shape the engineering study. As a result, the same physical asset can be examined at different levels, with its role shifting depending on whether the focus is on internal behavior, subsystem interaction, or broader system performance.

Example # 1 – Power Engineering Application

Consider a scenario where an electrical engineer is tasked with diagnosing a performance issue within a station power transformer. In this context, the system boundary is drawn tightly around the transformer itself. The transformer is treated as the system of interest, while its internal elements, including windings, insulation, core, oil, and cooling systems, are defined as subsystems and components. The analysis is therefore focused on internal interactions and how they behave within the physical and operational limits of the transformer. Any emerging issues are interpreted through internal mechanisms such as thermal stress, insulation breakdown, or chemical changes in the insulating oil.

Now consider the same transformer within the context of a provincial or national power grid study. In this case, the system boundary expands significantly, and the transformer is no longer the system of interest but becomes a single component within a much larger interconnected network. At this level, multiple transformers, transmission lines, and generators are represented as nodes within a power system model. Entire regions or zones of the grid may be treated as subsystems, while the full interconnected network is analyzed as a system to evaluate steady state power flow, voltage stability, contingency performance, and overall system reliability.

Why Engineering Systems Must Be Broken Down?

Breaking a system into subsystems and components provides clarity, traceability, and control. Each subsystem represents a functional grouping of components that collectively perform a defined role. Components, in turn, represent the smallest units of analysis where specific physical or functional behavior can be observed.

This hierarchical breakdown allows engineers to assign responsibilities, isolate issues, and evaluate performance at multiple levels. Without such a structure, complexity becomes unmanageable. More importantly, decomposition does not reduce complexity. It organizes it in a way that can be understood and managed.

Example # 2 Automotive Engineering Application 

Consider a vehicle braking system integrated with electronic stability control. At the system level, it is responsible for safe deceleration and maintaining vehicle stability under varying conditions. When broken down, it consists of subsystems such as wheel speed sensors, electronic control units, actuators, and braking hardware. Each performs a defined function, but overall performance depends on their real-time interaction.

Wheel speed sensors provide input to the control unit, which determines slip conditions and adjusts braking force through actuators. If a sensor provides inaccurate data or an actuator responds slowly, the entire system's performance is affected. This breakdown allows engineers to isolate issues at the sensing, control, or actuation level, making it possible to trace faults and understand how component-level behavior impacts the overall system.

Interactions and Governing Processes

Once a system is broken down, the next step is to understand how its elements interact.

These interactions are governed by physical processes such as energy transfer, signal exchange, thermal dynamics, fluid movement, and control logic. They may also include human interactions, such as operator decisions and maintenance actions. The key insight is that interactions define behavior. A well-functioning component can still contribute to system failure if its interaction with other components is not properly understood or managed.

Example # 3 Manufacturing Engineering Application 

Consider a lean manufacturing environment producing electromechanical assemblies. At a system level, the production line includes material handling, assembly stations, automated tools, inspection systems, and human operators. Each element may perform within its intended function, but overall system performance is governed by how these elements interact through timing, sequencing, torque application, thermal effects, and operator decisions.

An issue may emerge where assemblies consistently fail quality checks due to fastening defects. The torque tool may be calibrated and functioning correctly, yet variation in operator handling, part alignment, or tool wear leads to inconsistent outcomes. This reflects a breakdown in interaction between human input, equipment performance, and process control rather than a single-point failure.

To manage this, engineers rely on a combination of structured methods across the system lifecycle. At the design and planning stage, analytical approaches such as failure mode assessments are used to anticipate where interactions may lead to defects and to introduce controls early. As the system operates, real-world failure data is captured and analyzed through structured reporting processes, allowing engineers to understand how the system actually behaves under production conditions.

This analytical and operational feedback is then integrated into broader continuous improvement frameworks such as Lean and Six Sigma. Data is used to identify variation, isolate root causes, and refine both process design and execution. Improvements may include standardizing work methods, introducing error-proofing mechanisms, automating critical steps, or enhancing operator training.

Through this approach, the focus remains on managing interactions rather than isolated components. The system is continuously refined by aligning expected behaviour with actual performance, ensuring that human, machine, and process elements work together in a controlled and optimized manner across the entire lifecycle.

Conclusion

Competency 1.7 is fundamentally about how an engineer thinks in systems, not just how they understand components. It is built on three practical expectations: understanding the role of each element in a process, recognizing how those elements interact to produce overall system behaviour, and using that understanding to monitor and manage performance in a meaningful way.

In practice, this means an engineer is able to move between levels of detail without losing perspective. At one level, they can clearly explain what each component or subsystem is doing. At another, they can see how those parts work together, where constraints exist, and how behaviour emerges from those interactions. Beyond analysis, they can also engage with the system in operation, identifying issues and adjusting processes to improve outcomes.

Taken together, this competency reflects the ability to understand structure, interpret behaviour, and influence performance. It is this combination that allows engineers to work effectively in real systems where complexity is not removed, but managed.

Disclaimer:

The information provided in this blog is for general informational purposes only. While every effort has been made to ensure the accuracy of the content, the author does not guarantee the technical precision or completeness of any project details mentioned. The views expressed in this blog are based on publicly available information and personal insights and may not reflect the latest developments or technical changes. Readers should verify all technical information and consult relevant professionals before making any decisions based on the presented content.