APCOSE Proceedings

The terms module and modularity are used extensively in the Product Engineering (PE) literature. Modularity creates a product platform that facilitates product variety, customization and rapid upgradability. Today, modularity is an essential core competency of leading product designs, enabling organizations to maintain a competitive edge in the marketplace. However, module and modularity terms have very context specific definitions in System Engineering (SE) literature. Furthermore, the term module is not part of the technical taxonomy in any of the SE standards. These standards do not regard a module as a part of the formal system breakdown structure. In this paper, we attempt to redefine the term “module”, and to provide a technical specification/ontology for the term that might be as useful for systems engineers as it is for product engineers. In our view, in addition to a module being a set of components with interfaces between them, it must also serve one or more purely nonfunctional goals, such as flexibility, evolvablity, manufacturability,maintainability etc. Modules help designers and product managers in addressing ilities or system attributes that are non‐functional system attributes. A module must have interfaces with other modules and subsystems, and be encapsulated in a boundary. The interfaces can be standard, however this is not essential. Standard interfaces are useful for the creation of product/system platforms, as it allows repeated use of the same architecture. However, there are advantages associated with non‐standard interfaces, such as recyclability, maintainability, reusability, adaptability etc.The important assertion here is that a module’s boundaries do not necessarily coincide with those dictated by the functional decomposition. For example, module’s boundary can intersect several subsystems’ boundaries. Therefore, a module is not necessarily a configuration item or a subsystem, neither it is an assembly or a component. A module is a construct within a system with nonfunctional goals. Unlike a module, the “system”, subsystem and “system elements” have functional goals and must contribute to the functional requirements. For the sake of completeness we can define a function as a value delivering process that involves the transfer of material, information and/or energy. Modules do not necessarily contribute to the enhancement of functions. As shown over time, modularity may even reduce performance. A modular architecture is usually more complex than a non‐modular one due to the additional interfaces and redundancies that modular architecture might require. Modularity usually creates a tradeoff between achieving non‐functional attributes and functional performance