Teaching the Right Side of the V-Model: Learning Systems Integration by Doing

This quarter, I taught SE4151: Systems Integration and Development. I revised the course to incorporate SysMLv2 across the integration process, from interface design through component and subsystem qualification. Systems integration addresses the often-neglected right side of the systems-engineering V-model. In this article, I highlight several observations from the course.

A sensor can perform perfectly in a laboratory and still not be ready for operational use. My students experienced that difference firsthand this quarter in SE4151 Systems Integration. After weeks of studying integration theory, developing architectures, defining interfaces, managing configurations, and preparing test plans, they took their integrated sensors out of the laboratory and tested them on an unmanned surface vessel in a realistic environment. At that point, the central question was no longer simply, «Does the sensor work?» Instead, students had to ask:

«What evidence do we need to determine whether this sensor integration is qualified for its intended application?»

That distinction is at the heart of systems integration and at the heart of how I designed this course.

Photo: ENS William Haxton (USN) and LT Oumar Datt (USN) test their sensor in a lab environment.

Systems Integration is more than Assembly

Systems engineering is often illustrated using the V-model. Requirements, architecture, and design appear on the left side, while integration, verification, validation, and testing appear on the right. This representation is useful, but it can also create the impression that system development proceeds linearly. First, engineers design the system. Then, they build and test it.

In practice, evidence gathered during integration and testing frequently reveals that something on the left side must be reconsidered. The architecture may need to change. An interface may have been incompletely specified. A requirement may be ambiguous or impossible to measure. A selected technology may not be appropriate for the operational environment. I wanted students to experience this iterative relationship themselves.

The quarter-long project therefore challenged five teams of three students to integrate different sensors onto an existing unmanned surface vessel (USV). Each sensor supported a different operational concept:

• LiDAR for precise USV docking maneuvers

• A depth-sensing camera for detecting near-shore hazards

• Ping sonar for harbor patrols following storms

• Radio transceiver for radio transmission analysis

• A hydrophone for noise detection

The objective was not simply to mount the equipment and demonstrate that it could produce data. Each team had to develop a defensible method for determining whether its sensor integration was suitable for the intended application. That required a sufficiently detailed interface architecture, a realistic test plan, and thorough data analysis connected to defined requirements and measures of performance.

One reason I consider this capability particularly important for the Navy and Joint Force is that emerging technologies rarely operate as stand-alone systems. New sensors, software, autonomous platforms, and communication technologies must function within existing technical architectures and operational processes. Future leaders therefore need to assess not only whether a technology works, but whether it can be integrated, tested, and responsibly employed as part of a larger operational system.

Photo: Integrated LiDAR sensor for precise docking maneuvers.

Integration starts in the System Architecture

Before students physically integrated anything, they first had to understand the existing system. They analyzed the USV architecture, identified relevant functions and components, and considered constraints and external systems. They then investigated how the introduction of a new sensor would affect the system’s operational and technical interfaces. Students represented requirements, structures, behaviors, and interfaces using SysMLv2. To my knowledge, SE4151 was the first course at the Naval Postgraduate School to incorporate SysMLv2 in this way.

Learning the language and tool was important, but it was not the primary objective. I emphasized that building a model begins with establishing its purpose:

• Which engineering questions must the model answer?

• What information must be represented?

• Which relationships must be traceable?

• How will the model support integration and testing decisions?

Students used architecture models, interface diagrams, and Whitebox Interface Control Document tables to describe how the sensors interacted with the USV. This helped them see how a change to one component could propagate through mechanical, electrical, data, software, and operational interfaces. They also identified performance measures, traced them through the model, and linked them to requirements. An important part of the course was introducing interface requirements as a fundamental element of system architecture, integration, and qualification.

The model was not intended to serve only as graphical documentation. It became part of the students’ reasoning about the integration and qualification process.

Photo: LT Poling (USN) and LTC Joo Gek Dolly Sim (Navy Singapore) analyze the collected data from their USV and integrated sensor.

Technical Integration Requires Information Integration

Systems integration is a collaborative activity. Several engineers may simultaneously modify related system information, often while the physical system is evolving. Students therefore used Git to manage models and documents, coordinate parallel work, document revisions, and identify conflicts. They had to understand not only what had changed, but why it had changed and how simultaneous changes should be reconciled.

«Integration is not solely a system or product related activity, it affects the overall engineering process.»

Students experienced configuration management as part of the engineering work rather than as an administrative process added afterward. This turned out to work very well with the textual notation of SysMLv2. Students could easily see changes made by other team members and merge them into the USV’s base model.

Photo: LT Nicholas Chong (USN) and ENS Bryan Beekman (USN) present their work.

Moving from «It Works» to Defensible Evidence

Once students had developed their integration approaches, they moved into physical assembly and controlled laboratory testing. At this stage, students developed Operational Test Plans, test cards, verification cases, and analysis cases. Within their SysMLv2 models, they traced these cases back to the requirements that needed to be verified. A major learning objective was to move beyond statements such as «the sensor appears to work.»

Instead, students had to establish a logical chain:

Operational need → requirement → measure of performance → interface architecture & design → test condition → observed evidence → qualification decision

This required careful consideration of requirements, critical operational issues, measures of performance, and the evidence required to support a conclusion. Students also had to define repeatable test sequences and determine how the results would be recorded and analyzed.

The difference is significant. Observing that a sensor generates data is relatively easy. Demonstrating that its integration is suitable for a specific operational application requires much more precise reasoning.

Photo: LT Datt Oumar and ENS William Haxton present their work.

When Laboratory Performance Meets the Operational Environment

The depth-sensing camera provided one of the clearest demonstrations of why this distinction matters. During controlled testing, the camera performed well. The laboratory environment provided conditions in which the sensor could generate clear and useful depth information under water. When the team tested the same camera in lake water, however, its performance was substantially degraded. This was not a project failure. It was a valuable learning outcome. Students often learn about multicriteria decision-making, but may receive less exposure to where the evidence needed for that evaluation originates. Testing provides that evidence.

Testing is the key activity to provide this information. In a larger project, those results would inform the decision about which sensor or subsystem best supports the required mission capability.

It also prompted larger systems-engineering questions. Were the original requirements appropriate? Had the team selected measures that adequately represented operational suitability? Could the integration or test method be improved? Would a different sensing principle be required? The answer to an integration test is not required to be «yes» for the test to be valuable. A well-designed test should produce evidence that supports an engineering decision, including a decision to revise or reject the current solution.

Other teams encountered different manifestations of the same principle. During ping-sonar testing, wind affected the USV’s ability to follow the precise grid pattern envisioned in the Operational Test Plan. Students had to consider how this affected the validity of the test and make informed decisions about adapting the protocol.

The LiDAR team discovered a different type of integration effect. Although the LiDAR performed well during laboratory testing, the fully integrated configuration revealed that a USV antenna partially obstructed the sensor’s field of view. The effect was not critical for the demonstration, but it illustrated why component-level testing cannot reveal every interaction within an integrated physical system. The students addressed the obstruction by modifying the software to account for the affected portion of the sensor’s field of view.

Photo: Students from Singapore test their sensor in an operational environment.

Planning for the Unexpected

A good test plan provides structure, repeatability, and traceability. It cannot predict every environmental condition or every system behavior. Operational testing therefore requires both discipline and engineering judgment. When students encountered unexpected conditions, they had to determine whether and how to adapt their test procedures. An ad hoc change should not mean abandoning rigor. Students needed to document what changed, explain why the change was necessary, and consider how it affected the evidence they could collect.

This is one reason I place such emphasis on learning by doing. Students can study test planning, interface management, and configuration control individually. Their relationship becomes much clearer when students must apply them together to a physical system under real constraints.

Photo: LCDR Jessica Webster (USN), LT Michael Staples (USN) and MAJ Jose Moreno (Mexican Army), present their work.

Integration as an Iterative Learning Process

By the end of the quarter, I wanted students to understand that the architecture, physical design, integration approach, requirements, measures, and test strategy are not independent products. They form one connected engineering argument. An interface decision influences how the system can be assembled. The physical configuration affects the sensor’s performance. Operational conditions affect the test procedure. Test evidence may reveal that a requirement needs clarification or that a different solution principle should be considered. That iterative process occurs at multiple scales.

At a small scale, a team may revise an interface, test card, or verification method. At a larger scale, the evidence may indicate that the chosen sensor cannot be qualified for its intended application. In that case, the next iteration may require changes to the system architecture or the selection of a different technology.

This is not the integration process breaking down. It is the integration process doing what it is intended to do: generating evidence while changes are still possible.

Educational Outcomes

SE4151 brought together integration theory, interface management, architecture development, SysMLv2, Git, physical assembly, verification, and operational testing. More importantly, it allowed students to experience these topics as parts of one continuous engineering process.

They began with an operational problem. They translated that problem into architectures, requirements, interfaces, and measures. They integrated physical sensors, established controlled test conditions, collected evidence, and then evaluated their systems in a more realistic environment. By the end of the quarter, each team had produced an integrated sensor configuration, a SysMLv2 architecture and interface model, traceable requirements and performance measures, an operational test plan, and an evidence-based qualification assessment. More importantly, the students had practiced deciding what evidence was sufficient, identifying limitations in their methods and designs, and determining what should change in the next engineering iteration.

Some results confirmed what they expected. Others challenged their assumptions. Both were valuable.

The goal of systems integration is not to produce the answer we hoped to see. It is to generate reliable, repeatable, and defensible evidence that helps us make better engineering decisions.

For me, that is also the value of learning by doing. Students do not simply hear that systems engineering is iterative. They encounter a result they did not expect, examine what it means, and decide what the system needs next. Students leave SE4151 better prepared to evaluate whether a technology can function as part of a larger operational system, identify what evidence is still missing, and make responsible decisions before technical limitations become operational problems. This judgment will help them make better-informed decisions about the technologies considered for future Navy projects.

Photo: Posters created by the students showing their work.

Have you encountered similar systems-integration challenges? Are you interested in collaborating on systems-engineering education? Contact me!

____

(Cover Photo: Carlos Vallin)