Notes from [SWC98]:

• Definitions:
  • “Modules are defined as physical structures that have one-to-one correspondence with functional structures.”
  • “Modular products may be defined as machines, assemblies or components that accomplish an overall function through combination of distinct building blocks or modules.”
    • This overlaps at least partly with my use of “system.” A system is a functional unit. The difference is that systems don't necessarily map to physical structures.
      • But this also assumes I don't limit the sense of things like “safety systems” to distinguish between a characteristic and a system.
    • There is also the problem of behaviour. Which is not mentioned in this work. Function maps to behaviour which begets embodiments which…. Become modules?
• Key benefits: reuse in other products; easier maintenance (swap out modules); customization/personalization; reuse on decommissioning (rather than recycling).
  • Given these benefits, the real reasons for modularity have nothing to do with operation, but with variation of function over time. That may be the angle to take in building it into my system.
• Function dependencies are important too; they are manifested by the connections between functional blocks (flows of mass, energy, and information) that can vary over time.
  • This means that the function model (or architecture) can and should be used as a guide to run scenarios. This connects well to Patrick's stuff.

Dominant flow heuristic. A single flow that passes all the way through the system. The functions through which the flow passes is a module. Other flows may cross the dominant one; these represent interfaces with the module.

Branching flow heuristic. Given a flow that splits into branches, each branch can be a module. This means modules, like systems, are recursive. This in essence is like finding the subtrees of a tree graph.

Conversion-Transmission heuristic. A function chain that either (a) converts a flow, (b) converts a flow and then transports it, or © converts a flow then performs other functions and finally transports the flow, can be made a module.

TODO It would be nice to get the database of product decompositions that were used in this work. Apparently at UT Austin, referenced by other work I need to look up.