Electromechanical systems convert energy to mechanical work and vice versa. They feature control electronics (for example, an electronic control unit) or embedded controllers (for example, a line-replaceable unit) running purpose-built software that controls mechanics, actuation, and physical components using inputs from sensors and other systems. Electromechanical systems provide vehicle propulsion and serve a variety of other functions on aircraft, ground vehicles, and ships.
Figure 1. Example Vehicle Categories and the Common Types of Electromechanical Systems in Them
Though these systems’ functions, methods of action, and design requirements can vary widely, the development and test of electromechanical vehicle systems follow the same general workflow. Systems engineers design the overall vehicle and the requirements that must be met by the vehicle’s systems, subsystems, and components. Separate teams address these requirements by developing the appropriate control electronics, software, and mechanical components against specifications. These teams follow their own development processes (typically a common methodology such as Agile adapted to specific organizational needs) to progress through the design and validation steps for their specific pieces of the electromechanical vehicle system. Then, the system is iteratively built up, integrated, and tested in stages to produce the finished vehicle.
Figure 2. Generalized Product Development Process for Electromechanical Systems
The process of progressing from requirements through design and validation is represented in various ways, one of which is the V-model (Figure 3). Even with all the confusion surrounding the V-model and its many incarnations and interpretations, it is still a useful framework for examining the merits of a universal test architecture to address test needs across the design process.
Figure 3. The V-Model Method of Representing the Development Process and Associated Test Types
In general the left side of the V represents the breakdown of high-level requirements to lower-level specifications through progressive design decisions. These decisions are made using an increasingly model-based design approach that encompasses a variety of computer aided engineering (CAE) tools depending on the type of system under development. For more discussion on this topic, see the substantial literature on digital transformation and digital twinning. At the bottom of the V, the systems have been broken down into their lowest base-level components, the design is ready to be translated into implementation, and the component prototypes are ready to be built (and code deployed to the prototypes that run software, which is why the bottom of the V is sometimes labeled “deploy”). The right side of the V shows integrating these various pieces together, verifying their operation against specifications, and validating performance against requirements at each integration step from base-level components up to the vehicle level.
Note: As the system, subsystem, and component details are provided, the development of software, electrical components, and mechanical components progresses in parallel as shown in Figure 2. Separate design and test teams with the requisite domain expertise usually own the development process.
Note: The terms “verification” and “validation” are used somewhat indiscriminately, and sometimes the umbrella term “V&V” is used. Generally, during verification, you ask, “Am I building the thing right?” and make sure your system operates as expected (with tolerance or range) compared to a set of specifications. But during validation, you ask, “Am I building the right thing?” You make sure your system, once complete, can perform the tasks it was designed for with acceptable performance as measured against a set of requirements.
The short descriptions and definitions for the following tests are roughly in the order that you encounter them in the product design process, which is highly iterative in practice. The ability to quickly and efficiently progress through the design V to iterate on design is a competitive advantage and a key competency of a best-in-class test organization. One critique of the V-model is that it represents a sequential process like the Waterfall design methodology.