"Any customer can have a car painted any color that he wants so long as it is black"
- Henry Ford
Modularity in design is an approach that divides a system into smaller parts called modules that can be worked on independently and then reused in other systems. A modular system is characterized by breaking a larger system into discrete, scalable, reusable modules and using well-defined (or industry standard) interfaces. An automotive example is Volkswagen's MQB, which is a modular product architecture that yields an abundance of configuration options with a minimal set of standardized parts and modules.
Modularity offers many advantages to software designers. Modularity creates numerous options compared to non-modular designs. As an example, modules can be replaced individually as superior alternatives become available. Modularity makes complexity more manageable. A complex system can be better managed by dividing it up into smaller pieces and looking at each one separately. When the complexity of one of the modules crosses a certain threshold, that complexity can be isolated by defining a separate abstraction that has a simple interface. The abstraction hides the complexity of the module and the interface indicates how the module interacts with the larger system.
For humans, the only way to manage a complex system or solve a complex problem is to break it up into smaller, manageable pieces. Modularity enables teams to work on separate modules in parallel since the modules do not have any dependencies on each other.
Modularity is tolerant of uncertainty. Things can be changed after the fact and in ways not anticipated by the original designers as long as the design rules of the system are obeyed. Modular designs evolve as new or different options are pursued. This evolution creates value in terms of new products or new uses for existing products. This all leads to a reduction in development costs due to less customization, shorter learning time, and flexibility.
There is no such thing as a free lunch, so while there are many benefits to modularity, there are also associated costs. For a design to become modular, every important design dependency must be understood and addressed via one or more design rules. This coupling (or density of dependencies) also matters. A loosely coupled system is easier to modularize than a tightly coupled system. In software development, modularity is often sacrificed to budget and time pressures because of implementation costs and product-specific technical reasons.
Modularity is becoming an increasingly important part of automotive software. AUTOSAR focuses on a standard software architecture to fulfill requirements such as modularity, scalability, transferability, and reusability. To achieve these requirements, AUTOSAR provides a common software structure based on standardized interfaces for the different layers. The current version of AUTOSAR includes a reference structure and interface specification. AUTOSAR focuses on the standardization of interfaces and portability of code. The modularity is defined by the layered basic software architecture. Considerations are made for hardware-dependent and hardware-independent software modules. This enables the transfer of functional software components within a particular system.
In Automotive SPICE, evaluation of alternative solutions is required for both system and software architecture. The evaluation needs to be done according to defined criteria. Such evaluation criteria include quality characteristics like modularity, reliability, security, and reusability. The evaluation results, including an explanation for architecture and design decisions, must be recorded.
Product line software engineering (PLSE) has been recognized as a key concept used to meet the diverse needs of the global market effectively and to provide competitive advantages to an organization. Modularity in the context of PLSE has become vital as companies need to manage variability and also promote reuse across related software applications.
The first step in updating your code to become more modular is to set goals or objectives for the product modularization. This should include product requirements. The next step is to understand the software architecture and generate the product's functional structure (architecture). A dependency structure matrix (DSM) is a very easy, scalable way to understand the architecture.
Once you understand the architecture, you should arrange the structure in a hierarchy, or layers, based on the dependencies. This will involve extracting the dependencies from the codebase. Next, define possible modules and optimize the architecture. Identify your evaluation criteria and compare the modular alternatives, doing what-if analysis and impact analysis. Once you have defined the architecture, you need to implement your new modular architecture within the codebase itself. Finally, you need to establish rules to enforce and monitor your architecture. This will stop architecture erosion, which results from dependencies that violate the intended architecture crossing layer or modular boundaries.
Modularity is a great strategy for automotive software considering the number of standards (AutoSAR, ASPICE, ISO 26262) that include modularity as a key component. The software can be broken up into modules manually, but a solution like Lattix Architect can make defining and controlling your modular architecture much easier.