9th Asia-Pacific Conference on Systems Engineering (APCOSEC 2015)

Seoul, Korea. October 13-15, 2015

Ontological Description of Module in System Design

Mahmoud Efatmaneshnik*, Shraga Shoval, Sana Qaisar

School of Engineering and IT (SEIT)

THE UNIVERSITY OF NEW SOUTH WALES

UNSW CANBERRA AT THE DEFENCE FORCE ACADEMY

PO Box 7916 CANBERRA BC 2610 AUSTRALIA

Phone: +61 (0)459 144 349

Fax: +61 (0)2 626 88443

* E-mail:

9th Asia-Pacific Conference on Systems Engineering (APCOSEC 2015)

Seoul, Korea. October 13-15, 2015

ABSTRACT

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. 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. For the sake of completeness we can define a function as a value delivering process that involves the transfer of material, matter, 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.

KEYWORDS: module; modularity; system illities; non-functional requirements; system design.

1.  Introduction

Module and modularity are not Systems Engineering (SE) terms. The term module is not part of the system hierarchy description in any of systems engineering standards and handbooks, including SE INCOSE handbook, std IEEE 1220, ISO/IEC 15288, MIL-STD-499. A search in SEBOK (System Engineering Body of Knowledge) leads to no specific entry on either terms module or modularity. However, SEVOCAB (Software and Systems Engineering Vocabulary) gives the following definition for module followed by a specific note:

(1) A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading (ISO/IEC 19506:2012 …)

(2) Logically separable part of a program (ISO/IEC 19506:2012 …)

(3) Set of source code files under version control that can be manipulated together as one (ISO/IEC/IEEE 24765:2010 …)

(4) Collection of both data and the routines that act on it (ISO/IEC/IEEE 24765:2010 …)

Note: The terms 'module', 'component,' and 'unit' are often used interchangeably or defined to be sub elements of one another in different ways, depending upon the context. The relationship of these terms is not yet standardized.

A search in the literature of modularity in engineering reveals that module and modularity are widely used terms in product design and product engineering literature. In these streams of literature also equating “module” with “subsystem”, “component”, and “assembly” is common. The purpose of this paper is to provide separate ontological descriptions for each of these concepts. This will be particularly useful to SE community who, by virtue of following standard SE procedures, creates modular architectures.

In order to create a standard definition for ‘module’, and to clearly explain its ontological relation with a component or subsystem, we first look at common definitions of module and modularity mostly is product-engineering literature, where modularity topic has taken a serious discourse. Then we summarize the outlined benefits of modularity from this literature and note that they can all be categorized into non-functional type requirements. We then suggest the definition that “a module” is a grouping inside a system that has a non-functional purpose. Therefore the boundaries of a module are not necessarily the boundaries defined by functional units, namely subsystems and components.

1.1. Common Descriptions of the term “Module”

Etymologically, the word module comes from Latin word modulus meaning “a unit”. According to (Baldwin & Clark, 2000) modules in products and systems are units that are designed independently but still function as an integrated whole. (Ericsson & Erixon, 1999) defines a module as a structurally independent functional building block of a larger system with well-defined interfaces. (Schilling, 2000) defines it as a component of a system that is separable and performs a distinct function. (Erixon, 1996; Erixon, von Yxkull, & Arnstroem, 1996) describe modules as products in products. (Gu & Sosale, 1999) describes them as physically detachable units for rapid product development, ease of assembly, services, reuse, recycling and other product life cycle objectives.

The problem is that any component of any system is designed independently and has a distinct function. So all the above definitions are biased in a way that they assume there are some components that are not separable. In particular, the above definition does not answer any of the following questions:

1)  Can we consider anything well encapsulated and isolated as a module?

2)  Can we consider anything with an interface as a module?

3)  Does every module need an interface?

4)  Is it necessary that this interface is standard (unchanging)?

2.  Natural Hierarchy with SE

SE is generally a top down approach to designing and building systems. Every system that is built through SE principles and procedures is thus modular (or composed of modules) by the above definitions. Definition of system hierarchy in Fig. 1 shows that a system is composed of subsystems that are in turn composed of components. As mentioned, SE process in general is a top-down process, meaning that the system’s required functions are decomposed and derived from system goals and system objectives. The system hierarchy is a natural result of a one-to-one allocation of a set of hierarchical requirements to physical descriptions that satisfy those requirements. In principle, from SE perspective, a requirements set that is strictly hierarchical and which can be modeled by a perfect tree-like graph (which has no links between its leaves) is a healthy set of requirements and is a result of good requirements engineering practice.

Assignment of each functional requirement to a configuration item creates a natural modularity along the functional boundaries. For example the V-SE process is first based on decomposition logical or functional description, assignment of each functional requirement to a configuration item, and then the integration process, which includes test and validation. This process naturally creates a modular system that is modularized along the functional boundaries.

Fig. 1. System elements defined by functional boundaries (from IEEE 1220). System’s physical elements that have one-to-one mapping to elements of functional decomposition or logical description of the system.

The boundaries of the modules in a system does not need to follow the logical and functional boundaries of that system.

3.  Characteristics of Modularity

Decomposability is a fact of life. Anything and everything is decomposable, and has components, parts, atoms etc. However the ease of decomposability is different. Some parts are very difficult to separate from the system. A module certainly has the ease of separation as a character attached to it. The question is why do we want to create an artificial ease?

As a benefit, modularity generally makes it easier to maintain and evolve the system. This benefit of modularity is described extensively by (Baldwin & Clark, 2000) as the power of modularity. However there are limits to evolvablity benefit of modularity. For example, if the rate of market requirements change for a product is very slow, is it worthwhile to make it modular for redesign, given modularity itself requires investing of some intellectual capital? Modules and modularity also don't make much sense if the rate of change of the desired scope of the module's functionality in the target environmental context is so fast that the module is not likely to be replaceable with a newly designed module, because the technological landscape will change all too soon. Consider portable memory storage devices as example, 5 1/4" floppy drives, Zip drives, and miscellaneous hard drives and memory cards and USB sticks. Every one of these devices uses a different technology so that investment in modularization might not lead to a return, or incremental performance improvement.

The benefits of modularity include nonfunctional properties such as (Erixon, 1996):

  1. Evolvability, or technology push.
  2. Manufacturability, assembility, ease of production planning.
  3. Testability, verifiability (better test and verification).
  4. Style creation, customization, and modifiability.
  5. Reusability.
  6. Quality control.
  7. Better supplier management.
  8. Serviceability and maintainability.
  9. Upgradability.
  10. Recyclability.

Modularity and functionality have no positive relationship. If anything modularization process can have adverse immediate effects on functionality, just because it involves handling of functional structure for purposes other than purely functional goals.

Non-functional requirements have utilities for a specific system lifecycle, or a specific system stakeholder. For example, provision of modules to facilitate maintainability has utility for utilization period in system lifecycle.

4.  Module’s Definition

Modularity should not be regarded as a driver for functionality. It is quite the opposite. Modularity often has immediate negative consequences on functionality. How ever, in longer term it can improve functionality indirectly through facilitation of evolvability attribute. Tables 1-3 outline the major differences between module and other systemic objects such as the system itself.

Table 1. Outlines the main paradigms contributing why we need boundaries that make up objects.

Object / Main paradigm
System of systems / -Goal sharing
-Loose coordination
System / -Function sharing
-Functional synchronization
-Integration
-Delivery of complex functionality
Subsystem / -Simple function delivery
-Tight coordination
-High level of integrality
Component / -Single function delivery
-Finds value in system context
Module / -Delivery of system attributes/non-functional requirements

Table 2. Outlines the major stakeholders of system of systems, system, subsystem, etc.

Object / Main stakeholders
System of systems / -Government
-Enterprise
System / -User
-Developer/manufacturer
-Engineer/system engineer
-Enterprise
Subsystem / -Developer/manufacturer
-Engineer
-System engineer
-Supplier
-User
Component / -Supplier
-Developer
-Engineer
Module / -User
-Enterprise
-Supplier
-Developer
-Engineer

Table 3. Outlines the major decision parameters for boundary creation in each case.

Object / Main design parameters
System of systems / -Strategies for information sharing
System / -Types of technologies
-Developer/manufacturer
-Engineer/system engineer
-Configuration parameters
Subsystem / -Developer/manufacturer
-Engineer
-System engineer
-Supplier
-User
Component / -Choice of supplier
-Developer
-Engineer
Module / -Delivered dollar value of modularization against its cost, including the risk it might bear for functional capabilities.

Let’s define system part as system atoms that are the lowest possible decomposition that can be abstracted with still a relevance to the functional or performance requirements lists or system operational context. For example consider a bicycle’s spokes are its elements because they have functional relevance to bicycle but the iron ore that spoke was created from is not an element of the bicycle. This means that system boundary must set a limit for the level of abstraction as well as a limit across physical and temporal dimensions by which system elements can be described.

We can now proceed to define the notion of “module” in systems context:

A module is composed of some system parts, and is a detachable unit of a system that (that by virtue of this detachability alone) has a non-functional utility for a particular system stakeholder.

The same way the functional requirements map into the subsystems and so on, non-functional requirements map into modules. However the boundaries of the modules and subsystems are not necessarily identical. For instance a bicycle that I recently bought online came in 6 modules and a number of components that helped me attach these modules together. There were:

  1. front wheel
  2. pedals
  3. saddle
  4. handle bar grip with head tube and light
  5. back light
  6. everything else in one piece

This modularization is optimal design for a combination of deliverability, and ease assembly on the customer part, as well minimizing the negative impact of handling on the bicycle. The front handle bar had front safety light already attached to it. Although the function of the front handle bar (steering) is completely different from the front light (lighting) they came together a module. It is not right to call this piece as subsystem.

Fig 3 shows that the boundaries of a module are not necessarily those defined by system functions. Fig 4. Shows that different stakeholder can have interest in different types of modularization in the same system.

Fig. 3. A module’s boundary is not necessarily common with functional boundaries.

Fig. 4. Modular views of a system depend on the viewpoint and the viewer.

We propose to use module as preserved keyword indicating to segments of system that relate to a particular non-functional requirement or system ~ilities attribute. Therefore a module does not fit into the regular categorization of system physical hierarchy, which show direct mapping of functional hierarchy and physical hierarchy.

5.  Conclusions

To conclude we can state the following points with regards to ontological description of a module:

  1. If this stakeholder is a common stakeholder across many systems, then the detachment mechanism might be enforced by a standard interface.
  2. A module does not necessarily have standard interface. Having standard interface is should not be regarded as a criteria for a unit to be regarded as a module.
  3. A module should not necessarily have a unique function or some unique functions because the primary goal of modularization is non-functional. Having unique functionalities (again from certain perspectives) should not be regarded as a criterion for being regarded as a module.
  4. Subsystems, and components only have functional purposes attached to them.
  5. An assembly/subassembly is a module from manufacturing perspective or viewpoint.
  6. Every subsystem is a module. However a module is not a subsystem.

References

1.  Baldwin, C. Y., & Clark, K. B. (2000). Design Rules, Volume 1: The Power of Modularity: MIT Press Books.