Articles · November 12, 2026 · Luis Miguel Quevedo
How to design an engineering lab that does not age in two years
An engineering laboratory can become obsolete before its equipment does.
The problem is not necessarily that a power supply or oscilloscope stops working. Industry may change the way systems are designed while the laboratory continues teaching a frozen sequence. I see that as an educational architecture problem before it becomes an equipment-purchasing problem.
I have worked on this question in two papers presented at ASEE 2024. One examines an agile MBSE framework for designing an embedded-systems laboratory. The other applies MBSE to the design of a mechatronics, robotics and control laboratory intended to adapt to changing industry needs.
The central idea is simple: a laboratory is also a system.
It has users, objectives, interfaces, resources, constraints and verification criteria. A student needs to develop specific capabilities. Those capabilities translate into experiences. The experiences require equipment, software, content and assessments. When those relationships remain implicit, changing one part of the laboratory can affect several others without anyone seeing the connection.
MBSE provides a way to represent those relationships. It does not solve pedagogy automatically and it does not replace the instructor. It does, however, let us ask structured questions about what a student should learn, how that learning will be observed and which laboratory elements are necessary to support it.
That changes how we approach technology updates.
If a university wants to introduce FPGA design, for example, the first question should not be which development board to purchase. It should be which new capability the laboratory is intended to develop. Digital architecture? RTL? Verification? Interfaces? Physical implementation? The right hardware may differ depending on the answer.
The same applies to AI. Adding a generative tool to a class does not mean the curriculum has learned how to teach engineering with AI. We need to decide which activities can be automated, which decisions students must continue making themselves and how we will determine whether they understand the generated result.
In the embedded-systems laboratory work, MBSE was combined with agile practices including incremental development, continuous verification and continuous integration. The objective was to avoid a large up-front definition that could become outdated before completion and instead allow the laboratory to evolve in controlled increments.
The same logic appears in the mechatronics, robotics and control work. There, the problem is connected to the evolution of the semiconductor ecosystem and the need to prepare people for new manufacturing and automation environments. The model provides a way to connect learning objectives and capabilities with different technological scenarios.
This way of thinking also connects with my earlier experience. Before working on academic research, I spent years integrating robots, PLCs and industrial plants. In a plant, a modification rarely affects only one component. Changing a sensor may affect logic, wiring, sequence, safety and operation. Education behaves similarly: replacing a tool without revisiting the system around it often creates only a superficial update.
That is why I do not think a modern engineering laboratory should be designed around a fixed list of equipment. It should be designed around capabilities, interfaces and mechanisms for change.
The goal is not to predict which technology will dominate five years from now.
It is to build an educational architecture that can adapt when that technology arrives.
Book a free 30-minute callSee the education researchNewsletter on LinkedIn